HTTP Status Codes: The Server's Signal
HTTP status codes are the server's signal for a request's outcome: success, client error, or server error. You see them when fetching data (200 OK), hitting a bad link (404), or when a server fails (500). Footgun: Don't just check for 'not 200'.
Why it exists
The web is built on a request-response cycle between clients (like browsers) and servers. Without a standard way to communicate the result of a request, every interaction would be ambiguous. Status codes provide a clear, machine-readable signal about what happened, eliminating guesswork for developers and browsers.
The mental model
Think of HTTP status codes as a traffic light system for the internet. The first digit tells you the general category. 2xx is a green light (success), 4xx is a yellow light from your side (you, the client, made a mistake), and 5xx is a red light on the server's side (the server has a problem). 1xx are informational "hold on" signals, and 3xx are "go this way instead" detours.
How it works
Every HTTP response from a server must include a status code in its first line. This code is a three-digit number. The first digit defines the class of response, while the last two digits do not have any specific categorization role. The five classes are: 1xx (Informational), 2xx (Successful), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). For example, a 200 OK means the request succeeded. A 404 Not Found means the server couldn't find the requested resource. A 500 Internal Server Error means the server encountered an unexpected condition that prevented it from fulfilling the request.
When to use it
As a backend developer, you'll set status codes in your API responses to communicate outcomes clearly. For example, returning a 201 Created after a user signs up, a 400 Bad Request if a required field is missing, or a 401 Unauthorized if an API key is invalid. As a frontend developer, you'll read these codes to decide what to do next: render data on a 200, show a "not found" page on a 404, or display a generic error message on a 500.
When not to use it
Don't use status codes to communicate complex application-specific business logic. The biggest footgun is returning a 200 OK with an error message in the JSON body, like { "success": false, "error": "User not found" }. If the user was not found, the correct status code is 404 Not Found. The response body should only contain error details if the status code already indicates an error. Always use the most semantically appropriate code.
One canonical example
A user submits a new-user registration form via a POST request to /api/users. If the data is valid and the user is created successfully, the server should respond with a 201 Created status code. The response might also include a Location header pointing to the new user's resource, like /api/users/123. If the email was already taken, a 409 Conflict would be appropriate. If the password was missing, a 400 Bad Request would be the correct signal.
Interview question
When a server receives an API request where the client has omitted a mandatory piece of information in the request body, which HTTP status code class is most appropriate for the server to return?
- a.2xx, because the server successfully processed the request's receipt.
- b.5xx, because the server was unable to fulfill the request due to an error.
- c.4xx, as the client's request itself is flawed or incomplete.Correct
- d.3xx, to guide the client to a different resource that might accept the incomplete request.
Why? this is the answer
The card explains that 4xx codes indicate a client error, meaning the client made a mistake, such as sending a malformed request or missing required data. A 5xx code would signal a server-side issue, which is not the case when the client's input is incorrect.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #http
- #networking
- #web-fundamentals
- #api
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on http — each one lists the topics its interview covers.
See open roles