Code-Memo

HTTP Status Codes

2xx success codes

  1. 200 OK: generic success with a body (GET, PUT, PATCH, sometimes POST).
  2. 201 Created: resource created; pair with Location when useful.
  3. 204 No Content: success with no body (common for DELETE or updates with nothing to return).
  4. 202 Accepted: request accepted for async processing; return a way to poll status.

3xx redirection basics

  1. 301 Moved Permanently: old URL permanently replaced; clients may cache the redirect.
  2. 302 Found vs 307 Temporary Redirect vs 308 Permanent Redirect: method and caching behavior differ; prefer 307/308 when preserving the HTTP method matters.
  3. Use redirects sparingly in APIs; versioned base URLs are often clearer than chains of redirects.

4xx client errors

  1. 400 Bad Request: malformed syntax or failed validation the client can fix.
  2. 401 Unauthorized: authentication missing or invalid (naming is historical).
  3. 403 Forbidden: authenticated but not allowed.
  4. 404 Not Found vs 410 Gone: missing vs permanently removed.
  5. 409 Conflict, 412 Precondition Failed, 422 Unprocessable Entity (validation): use consistently for domain rules.

5xx server errors

  1. 500 Internal Server Error: unexpected failure; include a safe internal correlation id, not stack traces in production.
  2. 502 Bad Gateway / 504 Gateway Timeout: upstream or dependency failures behind gateways or load balancers.
  3. 503 Service Unavailable: overload or maintenance; pair with Retry-After when possible.

When to use each properly

  1. Pick the status that matches HTTP semantics, not your internal error taxonomy alone.
  2. Put machine-readable error codes in the body; keep the status code aligned with client behavior (retry vs fix request).
  3. Stay consistent across endpoints so clients can branch predictably.