Selecting the right status code improves client behavior, caching efficiency, SEO, and observability.

Pick the status class

flowchart TD A[Request handled successfully] A -->|Yes| S[2xx] A -->|No| Q{Client problem} Q -->|Yes| C[4xx] Q -->|No| E[5xx]
  • 2xx: the server accepted and completed the request.
  • 4xx: the request is invalid or not allowed.
  • 5xx: the server or an upstream failed to process a valid request.

Success details: 200 vs 201 vs 202 vs 204

flowchart TD S[2xx] --> K{Created new resource} K -->|Yes| C201[201 Created] K -->|No| P{Processing deferred} P -->|Yes| C202[202 Accepted] P -->|No| B{Response body present} B -->|Yes| C200[200 OK] B -->|No| C204[204 No Content]
  • 201 Created: the request created one or more resources. Location can identify the primary resource; otherwise, the target URI identifies it.
  • 202 Accepted: processing has not finished and might not occur. Describe the current status and provide a status monitor when available.
  • 200 OK: the request succeeded. The meaning of its content depends on the request method, and the content can have zero length.
  • 204 No Content: the action succeeded and there is no additional content or trailers to send.

The flowchart is a starting point, not a complete account of method semantics. A successful response with no content is not automatically a 204.

Conditional responses: 200 vs 304

flowchart TD P[Conditional request] P --> J{Representation changed} J -->|No| N304[304 Not Modified] J -->|Yes| N200[200 OK]
  • 304 Not Modified: a conditional GET or HEAD would have returned 200, but its condition evaluated to false. The client can reuse its stored representation.
  • 200 OK: the condition permits transfer of the selected representation, or the request was not conditional.

Authentication vs authorization: 401 vs 403

flowchart TD A[Access failed] --> X{Credentials present and valid} X -->|No| U401[401 Unauthorized] X -->|Yes| F403[403 Forbidden]
  • 401 Unauthorized: include WWW-Authenticate with the challenge.
  • 403 Forbidden: the server understood the request but refuses to fulfill it. Credentials might be present, but authentication is not a prerequisite for 403.

An origin can return 404 instead of 403 to hide the existence of a forbidden resource.

Validation vs business rules: 400 vs 422

flowchart TD V[Request invalid] V --> P{Syntax or schema malformed} P -->|Yes| B400[400 Bad Request] P -->|No| B422[422 Unprocessable Content]
  • 400 Bad Request: malformed JSON, wrong types, missing required fields.
  • 422 Unprocessable Content: syntactically valid but fails business rules or domain validation.

Redirects

See the dedicated guide: Redirects Deep Dive: 301 vs 302 vs 307 vs 308

CDN notes

  • HTTP defines 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 as heuristically cacheable. Explicit controls can permit or prohibit caching.
  • Short defensive caching for selected 4xx responses can reduce repeated origin requests when the cache key separates relevant request variants.
  • Retry and failover behavior is CDN-specific. Verify which network errors and status codes trigger it, and restrict retries to safe or idempotent operations.

See also