Junior Level

HTTP status codes are three-digit numbers that the server returns to the client to indicate the result of a request.

The first digit is the category: 2 = everything is fine, 4 = problem on your side (client), 5 = problem on our side (server). This helps with automated error handling.

Status code classes:

Class	Range	Meaning
1xx	100-199	Informational
2xx	200-299	Success
3xx	300-399	Redirection
4xx	400-499	Client Error
5xx	500-599	Server Error

Most common codes:

Code	Name	Description
200	OK	Request completed successfully
201	Created	Resource created
204	No Content	Success, no response body
301	Moved Permanently	Resource moved permanently
302	Found	Temporary redirection
400	Bad Request	Malformed request
401	Unauthorized	Not authenticated (login required)
403	Forbidden	Forbidden (insufficient permissions)
404	Not Found	Not found
500	Internal Server Error	Internal server error
503	Service Unavailable	Service unavailable

---

Middle Level

2xx: Success

• 201 Created: Return with a Location header
• 202 Accepted: For queue-based systems. “I accepted the task, ID is such-and-such, result will be ready later”
• 204 No Content: Ideal for DELETE and PUT. Saves bandwidth — no response body

3xx: Redirection

• 304 Not Modified: Key to performance. Used with Conditional GET (with If-None-Match). Server doesn’t send a body
• 307 Temporary Redirect / 308 Permanent Redirect: Unlike 301/302, these codes guarantee that the HTTP method won’t change (POST stays POST)

// 301/302 historically allowed browsers to change POST to GET on redirect.
// 307/308 were introduced to strictly preserve the method — critical for REST API.

4xx: Client Error

• 401 vs 403: 401 = no authentication (Identity unknown), 403 = no permissions (Identity known, but access denied)
• 409 Conflict: For business logic violations (duplicate email) or version conflicts in Optimistic Locking
• 422 Unprocessable Entity: Standard for validation errors (RFC 4918)

400 = “I didn’t understand your request” (syntax error, malformed JSON). 422 = “I understood the request, but the data fails validation” (email without @, password < 8 characters). The client knows from the code: fix the data, not the request format.

• 429 Too Many Requests: Signal from Rate Limiter. Always add a Retry-After header

5xx: Server Error

• 502 Bad Gateway: “Neighbor” problem. Nginx couldn’t reach the Java application
• 503 Service Unavailable: Server is overloaded or under maintenance. Load balancers should exclude the node from rotation
• 504 Gateway Timeout: Backend (Java) didn’t respond to the proxy server (Nginx) in time

Diagnostics

• Golden Signals: Error Rate is one of the four golden signals of monitoring (SRE)
• Log Correlation: Every error should contain a Trace-ID
• HTTP 500 in Java: As a rule, don’t return 500 manually — let the framework do it for unhandled exceptions. 500 should mean “something went wrong”, not “business logic forbade it”.

---

Senior Level

RFC 7807 (Problem Details)

Modern APIs (including Spring Boot 3+) are moving from simple codes to structured errors per RFC 7807 (RFC 9457 replaced RFC 7807 in 2023):

{
  "type": "https://example.com/probs/out-of-stock",
  "title": "Out of Stock",
  "status": 400,
  "detail": "Item ID 123 is no longer available",
  "instance": "/orders/456"
}

// type — URI documenting the error (machine-readable)
// title — short description for the developer
// status — duplicates the HTTP code
// detail — human-readable explanation
// instance — URI of the specific request (for logs)

Highload and Load Balancing

In high-load systems, the correct response code is critical for L7 Load Balancers, which use these codes to make “health” decisions (Health Check) about the service.

Negative Caching

CDNs (e.g., Cloudflare) can cache 404 or 500 responses to protect the backend from a “request storm” to non-existent resources.

Circuit Breaker

If a microservice starts returning 5xx codes, the upstream service should trigger the Circuit Breaker pattern to avoid “finishing off” the dying instance.

Hierarchy and Senior Nuances

• 307/308 guarantee method preservation, unlike 301/302 (which may change POST to GET)
• 422 is preferred over 400 for validation errors — more semantic
• 429 must always be accompanied by Retry-After for correct client behavior
• 500 is always an application bug, not a business error. For predictable business errors, use 4xx

Monitoring

• Errors (Error Rate) are one of the four golden SRE signals
• Every error should contain a Trace-ID to reconstruct the call chain
• Track latency histograms (P99) broken down by method (GET vs POST)

---

Interview Cheat Sheet

Must know:

• 5 status code classes: 1xx (informational), 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error)
• 200 OK, 201 Created (with Location header), 202 Accepted (for async tasks), 204 No Content (for DELETE/PUT)
• 301/302 may change POST to GET; 307/308 guarantee method preservation
• 400 = “I didn’t understand the request” (malformed JSON), 422 = “data fails validation”
• 401 = not authenticated (who are you?), 403 = no permissions (I know you, but you can’t)
• 409 Conflict — duplicate or version conflict; 429 Too Many Requests — rate limit
• 500 = application bug, 502 = backend not responding, 503 = overloaded/maintenance, 504 = backend timeout
• RFC 9457 (Problem Details) — standard JSON for errors: type, title, status, detail, instance

Common follow-up questions:

• When to use 422 instead of 400? — 422 for data validation errors, 400 for syntax errors in the request
• Why are 307/308 more important than 301/302 for REST API? — 307/308 preserve the HTTP method on redirect
• What is 202 Accepted for? — For async tasks: “accepted, will process later”
• Why is 500 always a bug? — 500 means an unexpected error; business errors should be 4xx

Red flags (DO NOT say):

• “400 and 422 are the same” — 400 = malformed request, 422 = data is invalid
• “301/302 preserve the method on redirect” — they may change POST to GET, 307/308 don’t
• “500 is a normal response for business errors” — business errors = 4xx, 500 = unexpected bug
• “401 and 403 are the same” — 401 = don’t know who you are, 403 = know you, but no permissions

Related topics:

• [[What is the difference between 401 and 403]]
• [[What is REST]]
• [[What is RESTful API design]]
• [[How to properly name REST endpoints]]
• [[What is Accept header]]