On Github minnesota-apis / october-2015-friendly-neighborhood-status-codes
Presented by Eric Caron / Made with Reveal.JS
As defined in the 1996 IETF RFC-1945:
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.Honestly, the 2014 HTTP/1.1 revision (RFC-7231) is a lot less painful.
The official list is maintained at http://www.iana.org/assignments/http-status-codes
Because reading the RFC is only slightly more fun than putting on socks.
You:
If you ever make up your own code,
Time for a live demo! We'll be using:
Now we'll dive into the codes themselves.
Sidenote: I'm going to try focusing on the ones related to API communications. Twitter and Twilio serve as the basis for ones that are useful (though I'll expand if everything perks my interest.)
Unless you're making your own Chrome-competitor from scratch, you'll never need any of these.
Represents 99% of all successful conversations on the internet. Expected response for GET. Permissable response for all other verbs, though that's subject to debate.
"Hey SmartBot7000, tell me your name."
HTTP/1.0 200 OK Content-Type: text/plain; charset=utf-8 SmartBot7000. You could've come up with something better.
Really should only be used when doing a POST and you're creating a document - this gives confirmation that it has been created.
"Hey SmartBot7000, the capital of Iowa is Capital City."
HTTP/1.0 201 CREATED Content-Type: text/plain; charset=utf-8 Good to know! I now know the capital of Iowa is Capital City.
Best for situations where you're deleting something and don't expect a change. When this happens in a web browser, they're not supposed to change the existing view.
"Hey SmartBot7000, I was wrong about the capital of Iowa - delete it from your memory."
HTTP/1.0 204 NO CONTENT
Note: Use this one sparingly. People like to get data back, and it makes them sad when they don't.
This is great for browsers, but pretty confusing for APIs. If you have a properly versioned API, you should never be killing an endpoint. Stay away from this one in your API. *Cue Eric's confession*
Ideal for times when the client has some cached content, and the server says that cache is fresh enough. Beyond query string parameters, ETag and if-modified-since headers can also trigger this response.
"Yo SmartBot7000. What's the most recent tweet by @ecaron in the last two hours?"
HTTP/1.0 304 NOT MODIFIED
Yes it is. 32 recognized errors, of which I think 10 are useful.
Which ones have people used?
400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 420 422 423 424 426 428 429 431 444 449 450 451 499The line between the Client and the Server causing the error is blurred. And confusing. Here's my rule of thumb:
Although everyone loves getting a 200, 400 and 500 are generic and hard to compensate for. Although the attached "Response Status Message" provides insight, it isn't intended to be a programmatic-decision maker. These codes tend to become a catch-all and make long-term support difficult.
Whenever you are reviewing code and see a 400 or 500, double check to see if there's something better.There probably is.
I could make up more, but that is really all you need. And they're both made by Runscope, and although this wasn't intentional it felt worthy of being acknowledged.
If you're a visual learner, though, you might want to check out http://httpstatusdogs.com/ or https://http.cat/. They give visual reminders - either in canine or feline flavors - of what the primary codes mean.