4

im currently working on a website which has Spring at backend and Angularjs at front side and we had discussed about back end responses to handle frontend's message dialogs and i have a question to ask:

Lets say i have an API : 

GET : /getstatistics
Request params : fromTime,toTime ( in timestamp format)

And if client make a request with invalid params like a string, which response code should be returned from server ? HTTP 400 bad request and response body with a message " fromTime and toTime should be in timestamp format" or HTTP 200 with same message?

I saw some Google's APIs for example Oauth, they're returning code 200 for a request with invalid access_token but ,in our project my opinion it should be HTTP 400 because Javascript has success and error callbacks, is it better for it just pop a red color dialog with message inside rather than a HTTP 200 code then still need to check the content of the message?

Any advides and opinions are appreciated.

Thanks!

meobeo173
  • 617
  • 1
  • 7
  • 20

3 Answers3

9

You should be returning a 400 error for bad request. Check out this reference.

The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Please have a look at RFC7231#section-6

A client MUST understand the class of any status code, as indicated by the first digit

and,

4xx (Client Error): The request contains bad syntax or cannot be fulfilled

Bad syntax can be something like you've mentioned in your question (making a request with invalid parameters, like a string).

I keep these two references handy whenever I'm designing RESTful APIs, might be helpful for you too:

  1. https://httpstatuses.com/
  2. http://www.restapitutorial.com/httpstatuscodes.html
Community
  • 1
  • 1
Divyanshu Maithani
  • 13,908
  • 2
  • 36
  • 47
  • Thanks, and i guess this is the reason of Google in my example – meobeo173 Oct 29 '16 at 14:38
  • @meobeo173 it might be sending 200 for successful redirection, not sure about that but I'm quite sure that sending error with 200 status isn't a good idea. You should be able to distinguish your response just by looking at the status code, not the payload IMHO. Also check out this SO link for further reference: http://stackoverflow.com/questions/27921537/returning-http-200-ok-with-error-within-response-body – Divyanshu Maithani Oct 29 '16 at 14:51
  • : "HTTP status codes are technical responses, NOT business logic responses" i found this quote, but in my situation, to ease client implementation i think it doesnt matter to response an error code for valid techical but invalid business logic request? – meobeo173 Oct 29 '16 at 15:13
  • @meobeo173 it's fine to respond with `200` where your business logic fails but since we're talking about REST where we are using HTTP as an application level protocol, it would be a better design to let your status code speak for itself (client side error -> 4xx, server side error -> 5xx). Although since there are no **definite** rules, the lines sometimes get blurry IMHO. – Divyanshu Maithani Oct 29 '16 at 17:13
  • @meobeo173 I've updated my answer and it should make more sense now. Although, in the end it sometimes comes down to your API design, hope this was helpful. – Divyanshu Maithani Oct 29 '16 at 17:20
  • Yeah , was digging around and there are so many arguments ,and yes,i think the code would better speak for itself. – meobeo173 Oct 29 '16 at 17:30
  • Glad this was helpful. – Divyanshu Maithani Oct 29 '16 at 17:55
2

Yes you are right, the http code should be 400 in your case. Your discussion here normally should be whether you need to return 400 or 422. For this you can check the accepted response for this SO question 400 vs 422 response to POST of data

Community
  • 1
  • 1
ettanany
  • 19,038
  • 9
  • 47
  • 63
  • Thanks, but i still need more details or some standards to understand . – meobeo173 Oct 29 '16 at 14:31
  • @meobeo173 I edited my answer to include more details. Also, you can find a more detailed response by following the link I added to my answer. – ettanany Oct 29 '16 at 14:59
0

I think it has something to do with how the parameters are used. If you use the resource, then a 404 should return. If the data is simply not valid then we decide to set a 409 Status to the request. It can't full fill it at 100% because of missing/invalid parameter.

HTTP Status Code "409 Conflict" was for us a good try because it's definition require to include enough information for the user to recognize the source of the conflict.

Reference: w3.org/Protocols/

Edit: In any case, the status code 200 is incorrect here because there is an error. In response, you can then return specific information like this:

{
  "errors": [
   {
    "userMessage": "Sorry, the parameter xxx is not valid",
    "internalMessage": "Invalid Time",
    "code": 34,
    "more info": "http://localhost/"
   }
  ]
}
Christian Alt-Wibbing
  • 343
  • 2
  • 8
  • What do you mean by how the parameters are used? I usually only return 404 if the resource itself is not routable/not found via URL (i.e a client made a call to /user instead of /users). 409 would make sense if there is something wrong with the state of the resource rather than the URL itself. In the OP's case, it sounds like the request parameter is malformed, hence a 400 would probably be more suited rather than 404 or 409. This is a good site I use for reference http://www.restapitutorial.com/httpstatuscodes.html – Derrick Oct 31 '16 at 04:37