HTTP status codes — Reading the result in three digits
Classify status codes into five classes by the hundreds digit before reading the last two digits. Distinguish success 200/201/204, redirects 301/302/308, client-side 401/403/404, and server-side 500/502/503.
Never freeze again at "what's the difference between 404 and 403?"
A screenshot of an error page arrives with "can you fix this?". Whether it is 404 or 403 or 503 completely changes the cause and the fix, yet by facial expression alone the numbers all look the same — status codes are a field where trying to memorize dozens of them ends in defeat.
No memorization is needed. The right way to live with status codes is to classify by the hundreds digit into five classes, then read only the few last-two-digit codes you actually meet. For the second item of the three-part set, "how did it go", the hundreds digit answers first.
Your first investigative move is decided by this classification. On 4xx, first suspect the request side (URL, authentication, what you sent); on 5xx, suspect the server side (application logs, downstream services). Just not getting this direction backwards finishes half of any root-cause investigation.
Classify into five by the hundreds digit, then within each class read apart only 'the few you often meet' — this is the map of status codes. The representative codes at the arrow tips are everything this chapter covers.
2xx — even success has distinctions
Success is not just 200. Here are the three you meet often.
When you become the one building an API, whether you can use these three properly changes how readable your replies are. Conveying not just "it succeeded" but "it succeeded, and here is what happened" in three digits — that is mastery of 2xx.
Practice 3-1 — Classify by the hundreds digit
First classify by the hundreds digit, then read apart the last two digits within the success class.
Q1. Which is the correct reading of the hundreds digit of a status code?
4xx says 'there is a problem with how you asked' (nonexistent path, missing permission, and so on), while 5xx says 'your request was received, but we fumbled the processing' — a server-side failure. Memorize this direction backwards and your first investigative move goes wrong. Read the hundreds digit, then the last two — that is this chapter's pattern for avoiding rote memorization of all three digits.
Q2. When POST /orders succeeds in creating a new order, which status code conveys the meaning most precisely?
201 is the success code that makes explicit 'it succeeded, and as a result a new resource was created' — many APIs attach the URL of the created thing in a Location header. 200 would not be outright wrong, but the information 'something was created' is lost. 204 means 'succeeded but there is no body to return', and 301 is a redirect; among the success codes, 201 is the most precise fit.
Q3. DELETE /orders/7 succeeded, and the server has no particular body to return. Which status code is natural here?
204 is the success code meaning 'it succeeded, but the body is empty' — a perfect fit for operations like deletions and updates that have nothing to return. 404 is a failure ('not found'), 500 is a server failure, and 100 is a 1xx (an interim progress note), not a report of success. Even success has its 200/201/204 distinctions — that is the point of reading 2xx.
3xx — the flavors of "please go elsewhere"
A 3xx response is a notice saying "the answer is not here — please go to the URL written in the Location header". On receiving it, the browser automatically re-requests the destination. The three you meet often differ along two axes.
The second axis, "method preservation", is a product of history. For compatibility with old implementations, 301/302 tolerate a POST being rewritten into a GET when redirecting. For a moved HTML page there is little real harm, but if an API's POST turns into a GET, the favor itself changes. Hence 307/308, which state explicitly that they 'do not change the method', were added later. Permanent or temporary × method-preserving or not — those two axes organize all four codes.
4xx and 5xx — naming whose problem it is
Within 4xx, telling apart three lookalike siblings matters most.
Within 5xx, telling these three apart changes your first move in incident response.
Reading 502 well is powerful because most modern web servers are a two-stage setup: "relay (nginx and the like) + application behind it". A 502 even tells you that the relay is alive and the thing behind it is down. One number narrows the place to investigate by a whole stage.
Practice 3-2 — Telling apart redirects and errors
The distinctions within 3xx, and within 4xx and 5xx. Your first investigative move in practice changes.
Q4. You permanently moved a site from http://example.com to https://example.com. Which is the correct reason to choose 301?
301 Moved Permanently declares 'this address is over there from now on' — browsers may cache the redirect so they can go straight to the new URL next time, and search engines carry their evaluation over to the new URL. A temporary move must not be cached or re-registered that way, so it uses 302 Found. Permanent or temporary — that one word of difference splits SEO and caching behavior.
Q5. Which is the correct reason 308 Permanent Redirect exists separately from 301?
Due to a history rooted in old browser implementations, 301/302 tolerate a POST being rewritten into a GET when redirecting. For an API that must be redirected as a POST, that changes the favor being asked, body and all. 308 (permanent) and 307 (temporary) are newer codes that state explicitly that they 'preserve the method'. The difference is not speed or being HTTPS-only.
Q6. A logged-in regular user accessed the admin panel https://example.com/admin and was denied. Which code most precisely expresses 'the page is not missing; authentication succeeded but permissions are insufficient'?
403 means 'I know who you are, but you are not allowed to do this'. 401, despite its name, means 'unauthenticated — please authenticate first', and retrying with credentials attached may succeed. 404 means 'no resource found at that path'. Note that sites wanting to hide the very existence of an admin panel sometimes deliberately return 404 for insufficient permission — keep in mind that a code is a statement of 'what the server claims', which pays off in the Chapter 7 cases.
What to take from this chapter
- Status codes come in five classes by the hundreds digit — interim / success / redirect / client-side problem / server-side failure. Your first investigative move is decided here
- The success distinctions: 200 general purpose / 201 created / 204 succeeded with no body
- Redirects run on two axes: permanent or temporary × method-preserving or not — 301, 302, 308 (and 307). Permanent ones get cached and carry SEO evaluation over
- Tell apart 401 unauthenticated / 403 insufficient permission / 404 nonexistent, and 500 inside the app / 502 the thing behind is down / 503 temporarily unable
Now that you can read the results, the next chapter takes on the third item of the three-part set — the "conditions and notes" attached to the correspondence: headers.