1

I am making a RESTful API and I am wondering what the RESTful way to handle 'junk' query parameters is. Currently I have a parameter that can limit the returned data;

my.api.com/v1/users?limit=2

But if instead I receive either a spelling mistake

my.api.com/v1/users?limti=2

or a parameter that is not implemented

my.api.com/v1/users?order=asc

should I return an error JSON response or totally ignore it (i.e. its the users responsibility to check the response is correct).

I would usually use the error response way but I notice that many websites/services simply ignore the incorrect parameters.

myol
  • 6,385
  • 18
  • 64
  • 110
  • 1
    Refer this post - It is having a lot of info on the REST api and query parameters http://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters – Clement Amarnath Jun 27 '16 at 14:08
  • 2
    You probably are going to end up using some defaults, some of them because you don't want to return 10000000 records if they miss the limit parameter and some for convetion (ORDER BY). I would NOT return a 404 if the parameter is not correct, a 404 means that the resource does not exist which it does. – Borjante Jun 27 '16 at 15:13

1 Answers1

0

The query parameters are part of the identifier for the resource. See RFC-3986

The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.

Therefore, the important question to ask in response to 

GET my.api.com/v1/users?limti=2

is: does this resource exist?

To me, that URI looks like a client error; as a consumer of your API, I would prefer that your endpoint notify me of the mistake that I made (404 looks appropriate), rather than returning me an arbitrary response that isn't what I want. "Fail fast" makes the problem a lot easier to discover.

But it's just as valid to say "yes, that resource does exist -- here's a representation of it" and pass back whatever your like. That's not helpful, but it isn't wrong either. After all, it's what you would end up doing if my spelling error happened by luck to actually match the spelling of a resource in your system. Consider, for instance, what your api is going to do when I ask for my.api.com/v1/users?limit=2 when what I wanted was my.api.com/v1/suers?limit=2

A compromise (which might be worst of both worlds) would be to redirect the client to a real resource in your system. For example, if you were just going to ignore the order=asc parameter, then it might be friendlier to redirect the client to my.api.com/v1/users, rather than just handing back that representation arbitrarily.

VoiceOfUnreason
  • 40,245
  • 4
  • 34
  • 73