Extra Query parameters in the REST API Url

Question

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

Answer 1

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.