15

When a client invokes my REST-ful service, it needs to know if the response came back was 'from me' or rather a diagnosis from the containing web server that something awful happened.

One theory is that, if my code is called, it should always return an HTTP OK(=200), and any errors I've got to return should be just represented in the data I return. After all, it's my code that gets the response, not the naked browser.

Somewhat self-evidently, if I'm using REST to generate HTML read directly by a browser, I absolutely must return an error code if there's an error. In the case I care about, it's always Javascript or Java that is interpreting the entrails of the response.

Another possibility is that there is some family of HTTP status codes that I could return with a high confidence that it/they would never be generated by a problem in the surrounding container. Is this the case?

bmargulies
  • 97,814
  • 39
  • 186
  • 310

2 Answers2

17

I use the following:

GET

  • 200 OK
  • 400 Bad Request (when input criteria not correct)

POST

  • 202 Accepted (returned by authorization method)

  • 401 Unauthorized (also returned by authorization)

  • 201 Created (when creating a new resource; I also set the location header)

  • 400 Bad Request (when data for creating new entity is invalid or transaction rollback)

PUT

Same as POST

  • 201 Ok
  • 400 Bad Request

DELETE

  • 200 OK
  • 404 Not Found (same as GET)
Jason Watts
  • 3,800
  • 29
  • 33
  • Does your client code look at any payload that comes back with these errors? – bmargulies May 11 '11 at 21:31
  • With 202 Accepted, I set the auth header. With 400's i will pass an error message, validation message in the body. With 201, you set the location header with the url of the created resource. – Jason Watts May 11 '11 at 21:33
  • OK. I'm thinking about a full-blown body, like a slug of json that gives, oh, a detailed error description or something like that. Or a stack trace with content-type text/plain. – bmargulies May 11 '11 at 21:35
1

I would not know how to avoid that some container returns codes like 404.

4xx codes are meant to handle client errors along with possibly some entity that describes the problem in detail (and thus would mean a combination of both of your mentioned approaches). Since REST relies on HTTP and the according semantics of status as well as methods, always returning 200 in any possible case is a violation of this principle in my opinion.

If you for instance have a request such as http://foo.com/bar/123 which represents a bar ressource with id=123 and you return 200 with some content, the client has no chance to figure out if this was the intended response or some sort of error that occured. Therefore one should try to map error conditions to status codes as discussed in REST: Mapping application errors to HTTP Status codes for example.

Community
  • 1
  • 1
Dirk
  • 1,893
  • 1
  • 19
  • 26
  • Well, but the reality of the situation is that it's easy to get a 4xx from any web server that indicates some problem like the wrong URL. And when that happens, the content is unpredictable. So it's unsafe for the client to examine it. – bmargulies May 11 '11 at 21:24
  • Hm, its of course true that you can't tell if the server / entity that send a 4xx status can be trusted as much as you can't determine if the content send by the "real" service is trustworthy without using mechanisms as HTTPS for example. It's still up to the client to handle the response appropriately and not execute any arbitrary content sent back or follow each redirect. Do you see any scenario where this could be extraordinarily dangerous compared to "normal" HTTP usage? – Dirk May 11 '11 at 21:39
  • It's not dangerous in the security sense, just inconvenient in the programming sense. It seems the simplest thing in the world, when coding a client, to want to send in a request and then be able to examine the response, without having to use heuristic guesses to tell if the response came from my service or from a server config problem. – bmargulies May 11 '11 at 21:42
  • 1
    "Since REST relies on HTTP...". REST is independent from HTTP. – insipid Mar 07 '13 at 20:46