Extra Query parameters in the REST API Url

问题:

In my Rest application, the resource url also support query parameters like pageSize, pageNum , name etc. So the request url looks like

/resource/{id}?pageNum=1&pageSize=25&desc="hello"

Now suppose a client adds an extra query parameter say 'lang' which my server is not supporting like

/resource/{id}?pageNum=1&pageSize=25&desc="hello"&lang="eng" , but my server doesnt support any lang parameter.

what should be the best design decision

Option 1 : Ignore the extra invalid queryparam and serve the request.

Option 2 : Throws bad request message to the client.

Thanks in Advance Singla

回答1:

Just ignore it. Most other web servers would ignore request parameters it didn't understand.

Google ignore my two extra parameters here https://www.google.com/#q=search+for+something&invalid=param&more=stuff

回答2:

No Doubt that clients must stick to the Api docs.

But what about certain changes in the APis ( just a small changes which does not involve migrating to a new API version )

Like say, an API resource : /dummy/api/Iid1 supports 3 query parameter, namely, a, b, c

so the complete URi : /dummy/api/Id1?a=1&b=20&c=45 is a valid request exposed by the API, and all the query params i.e a, b, c are optional params, i.e if these params are not present in the request, then the server processes them to some default value like a = 0, b = 0, c= 0

Over sometime, a large number of clients build their application based in the above URL scheme.

Now the API provider, wants to scrap off the parameter 'b' and decides to throw off exception on extra/unknown parameters

This would , mean that all the clients application build around the last URL scheme that involved parameter 'b' would fail !

This simply suggests that, throwing exceptions for extra/unknown query parameters, invariably, leads to a tight coupling of client and server concerns, which I guess, completely goes against the REST principles, which probably has a central theme to 'completely separte client and server concerns, so that both can evolve separately'

So I think only the missing/invalid 'mandatory' params should throw an exception, and not the options ones, never.

回答3:

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)

回答4:

Ignoring it is common pattern, but query parameters are also part of URL (the resource id) and proper response code on this kind of request is 404 Not Found.

There is no general design pattern. You have to ask yourself what is best for your users. Is better to tell them that the resource they are asking is not available in the format they required or just give them another resource?

Note

HTTP contains great mechanism for dealing with languages; see Accept-Language and Content-Language headers (all browsers are using it)