HTTP Status Codes

NetworkingMidnetworking

The Question

What are the main HTTP status code categories and key codes?

What a Strong Answer Covers

• 2+ codes per family
• 4xx = client error not backend
• 401 vs 403

Senior-Level Answer

HTTP status codes are three-digit integers grouped into five classes by their leading digit. Understanding the distinction between classes, and the semantics of individual codes, is essential for building correct APIs and debugging client-server interactions.

**1xx Informational** codes indicate a provisional response. The most common is `101 Switching Protocols`, returned when a server agrees to upgrade to WebSocket.

**2xx Success** codes confirm the request was received, understood, and accepted. `200 OK` is the general success response for GET and POST. `201 Created` signals that the request resulted in a new resource; the `Location` header should point to it. `204 No Content` confirms success with no body—used for DELETE or PATCH when nothing needs to be returned. `206 Partial Content` is returned for range requests (e.g., video streaming).

**3xx Redirection** codes require the client to take additional action. `301 Moved Permanently` and `302 Found` are the classic redirects; browsers cache 301 permanently, making it hard to revert. `304 Not Modified` is returned on conditional GET when the cached copy is still fresh—it carries no body, saving bandwidth. `307` and `308` are the method-preserving equivalents of 302 and 301 respectively: the HTTP method must not change during the redirect.

**4xx Client Error** codes indicate the request was malformed or unauthorized. `400 Bad Request` is a generic parse/validation failure. `401 Unauthorized` means authentication is required or failed—despite the name, it is about authentication, not authorization. `403 Forbidden` means authenticated but not permitted. `404 Not Found` means the resource does not exist at that URI. `409 Conflict` signals a state conflict (e.g., duplicate resource). `422 Unprocessable Entity` is preferred for semantic validation failures in REST APIs. `429 Too Many Requests` signals rate limiting.

**5xx Server Error** codes indicate the server failed to fulfil a valid request. `500 Internal Server Error` is the generic catch-all. `502 Bad Gateway` means an upstream proxy received an invalid response. `503 Service Unavailable` means the server is temporarily overloaded or in maintenance—should include a `Retry-After` header. `504 Gateway Timeout` means the upstream did not respond in time.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying 401 means 'not authorized'—it means unauthenticated; 403 is authorization failure.
• Confusing 502 (bad gateway response) with 503 (server unavailable) and 504 (gateway timeout).
• Using 200 with an error body instead of an appropriate 4xx/5xx code.
• Not distinguishing 307 (method preserved, temporary) from 302 (method may change, temporary).

Follow-Up Questions

• When should an API return 422 instead of 400? — 400 for malformed syntax/parse errors; 422 for syntactically valid but semantically invalid payloads (e.g., start_date > end_date).
• Why should you avoid caching 301 redirects aggressively in an API context? — Browsers/clients cache 301 permanently; if the redirect target changes later, cached clients never see the update.
• What HTTP status code should a rate-limited endpoint return, and what headers should accompany it? — 429 with Retry-After and optionally X-RateLimit-Limit / X-RateLimit-Remaining headers.
• How does a client handle a 503 correctly in a retry loop? — Honour the Retry-After header, apply exponential backoff with jitter, and set a max retry budget.

Related Questions

• TCP — 3-Way Handshake
• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• WebSockets