HTTP status codes are grouped into five classes by their first digit, and choosing the right one lets clients react correctly without parsing the body.
2xx Success — the request worked
3xx Redirection — further action / resource moved
4xx Client error — the caller did something wrong
5xx Server error — the server failed
2xx
200 OK — general success (GET, PUT, PATCH).201 Created — a resource was created (return a Location header).202 Accepted — accepted for async processing, not done yet.204 No Content — success with no body (common for DELETE).4xx
400 Bad Request — malformed syntax or invalid input.401 Unauthorized — not authenticated (no/invalid credentials).403 Forbidden — authenticated but not allowed.404 Not Found — resource doesn't exist.409 Conflict — conflicts with current state (e.g. duplicate email).422 Unprocessable Entity — well-formed but fails validation.429 Too Many Requests — rate limited.5xx
500 Internal Server Error — an unexpected server fault.503 Service Unavailable — temporarily down/overloaded.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
The key distinction interviewers probe: 401 ("who are you?") vs 403 ("I know you, but no"), and 400 (bad syntax) vs 422 (valid syntax, invalid data).
Status codes are the primary signal in a REST response — clients, proxies, monitoring, and retry logic all key off them, so getting them right is essential for interoperability. A common failure is returning 200 OK with an { "error": ... } body: it forces every client to parse the body to know if the call succeeded, breaks generic HTTP tooling, and hides failures from monitoring. Precise codes also drive automatic behavior: a 429 or 503 tells a well-built client to back off and retry, while a 4xx says "don't retry, fix the request." Interviewers use this question to check that you understand HTTP as a contract rather than a dumb transport, and that you distinguish the subtle pairs (401/403, 400/422) correctly — a hallmark of someone who has built and consumed real APIs.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate