I'm designing a RESTful API and faced with the title problem, restated for clarity:Should I fail fast if a client sends an unrecognized parameter? For example,http://example.com/api/foo?bar=true&paula=beanIn the above, bar is a valid parameter but paula is not specified by the API. Should IWarn the client of the errorFail fastIgnore itIf I warn the client, I can only issue a warning for the first parameter, since they could be sending a near-infinite number of them, and the server presumably has better things to do. Similarly, when failing, it would only specify the first invalid param as the problem.I prefer failure over issuing a warning to force the programmer to take action, as they might otherwise ignore the problem and keep wasting resources, or end up cargo-culting themselves inadvertently. Doing nothing is even worse in that respect.Do my arguments make sense? Is there an accepted practice on such things?
Should I be permissive of unknown parameters?
rest;api design
In my opinion, you should return an Invalid Request status, so that the client knows that what it's trying to do isn't valid. My opinion on this is influenced by the concept that RESTful APIs are discoverable. If you're providing sufficient information up front, then the client never tries to make an invalid request to begin with. If it does, then there's something wrong in the client code and failing fast will alert the second to this bug. Of course, that's a very purist approach and may not be recommended if your API isn't discoverable. A more pragmatic approach may be to ignore the invalid params, but either way you go, be sure to document the behavior well. 