CODEWITHSUNDEEP
rest
Mayank Goyal
Mayank Goyal

Reputation: 87

Should a wrong parameter passed via REST call throw an error?

I was accessing REST calls, when I passed wrong parameter to GET request it does not throw any http error. Should the design be changed to throw a http error or wrong parameter can be passed to REST call.

Example 1:(parameters are optional) https://example.com/api/fruits?fruit=apple

Give list of all apple elements

Example 2: https://example.com/api/fruits?abc=asb

Give list of all fruits

My question is related to example 2, should example 2 throw an error or is it behaving properly?

Upvotes: 0

Views: 1706

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

For a GET request, the request-line is defined as follows

request-line   = 'GET' SP request-target SP HTTP-version CRLF

where request-target "...identifies the target resource upon which to apply the request".

That means that the path /api/fruits, the question-mark ? and the query abc=asb are all part of the identifier.

The fact that your implementation happens to use the path to route the request to a handler, and the query to provide arguments, is an accident of your current implementation.

That leaves you with the freedom to decide that

  1. /api/fruits?abc=asb does exist, and its current state is a list of all fruits
  2. /api/fruits?abc=asb does exist, and its current state is an empty list
  3. /api/fruits?abc=asb does exist, and its current state is something else
  4. /api/fruits?abc=asb does not exist, and attempting to access its current state is an error.

My question is related to example 2, should example 2 throw an error or is it behaving properly?

If abc=asb indicates that there is some sort of error in the client, then you should return a 4xx status to indicate that.

Another way of thinking about the parameter handling is in terms of Must Ignore vs Must Understand.

As a practical matter, if I'm a consumer expecting that my filter is going to result in a small result set, and instead I end up drinking a billion unfiltered records out of a fire hose, I'm not going to be happy.

I'd recommend that in the case of a bad input you find a way to fail safely. On the web, that would probably mean a 404, with an HTML representation explaining the problem, enumerating recognized filters, maybe including a web form that helps resend the query, etc. Translate that into your API in whatever way makes sense.

But choosing to treat that as a successful request and return some representation also works, it's still REST, the web is going to web. If doing it that way gives you consumers a better experience, thereby increasing adoption and making your api more successful, then the answer is easy.

Upvotes: 0

Paul Mignard
Paul Mignard

Reputation: 5914

It's pretty common to ignore parameters that you aren't necessarily expecting. I think example 2 is behaving as it should.

I know that depending on the browser I would sometimes append an extra variable with a timestamp to make sure that the rest call wouldn't be cached. Something like:

https://example.com/api/fruits?ihateie=2342342342

If you're not explicitly doing anything with the extra parameter then I can't see the harm in allowing it.

Upvotes: 4

Related Questions