In my Rest application, the resource url also support query parameters like pageSize, pageNum , name etc. So the request url looks like
/resource/{id}?pageN
I guess ignoring bad parameters is standard practice, but it seems totally wrong to me in many cases.
Say I have a widget API with a widgets collection endpoint that finds widgets. Widgets have a foo attribute, so the following searches for widgets where foo = bar
GET https://example.com/widgets?foo=bar
Now an API client makes a typo.
GET https://example.com/widgets?foi=bar
Instead of returning only widgets where foo = bar, the typo is silently ignored and all widgets are returned (properly limited to some default size because I make well-designed API). My API client could spend hours trying to figure out why her call isn't working, or more likely light up my support site wondering why my API sucks.
Isn't it better to return a 400 status with an error message stating that "foi" is not a recognized parameter? This seems especially true because for the same kind of typo in a request body the best behavior is to return 400. (For example, see this answer: https://stackoverflow.com/a/20686925/2716301)