Question

The HTTP/1.1 specification (RFC2616) defines a number of status codes that can be returned by HTTP server to signal certain conditions. Some of those codes can be utilized by web applications (and frameworks). Which of those codes are the most useful in practice in both classic and asynchronous (XHR) responses, in what situations you use each of them?

Which codes should be avoided, eg. should applications mess with the 5xx code range at all? What are your conventions when returning HTTP codes in REST web services? Do you ever use redirects other than 302?

Answer 1

The ones I’m using (that I could find with a quick grep 'Status:' anyway):

• 200 Successfully retrieved a resource without affecting it
• 201 Sent whenever a form submission puts something significant into the database (forum post, user account, etc.), creating a new resource
• 204 Sent with empty body, for example after a DELETE
• 304 HTTP caching. I’ve found this one is very hard to get right since it has to account for users changing display settings and so on. The best idea I’ve come up with for that is using a hash of the user’s preferences as the ETag. It doesn’t help that most browsers have unpredictable and inconsistent behaviour here…
• 400 Used for bad form submissions that fail some validation check.
• 403 Used whenever someone is somewhere they shouldn’t be (though I try to avoid that by not displaying links to stuff the users shouldn’t access).
• 404 Apart from the normal webserver ones I use these when the URL contains invalid ID numbers. I suppose it’d be a good idea to check in this case whether a higher valid ID exists and send a 410 instead…
• 429 When user’s requests are too frequents
• 500: I tend to put these in catch{ } blocks where the only option is to give up, to make sure something meaningful is sent to the browser.

I realise I could get away with simply letting the server send ‘200’ for everything, but they save a lot of pain when users are seeing (or causing) errors and not telling you about them. I’ve already got functions to display access-denied messages and so on, so it’s not much work to add these anyway.