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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…