Which HTTP status codes should a REST API return?
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Group them by intent and be consistent:
- 2xx success: 200 OK, 201 Created (with
Location), 202 Accepted for async work, 204 No Content after DELETE. - 3xx: 301/308 for permanent redirects, 304 Not Modified for conditional GET.
- 4xx client errors: 400 malformed syntax, 401 unauthenticated, 403 forbidden, 404 not found, 405 wrong method, 409 conflict, 412 precondition failed, 415 unsupported media type, 422 semantic validation failure, 429 rate limited.
- 5xx server errors: 500 unexpected failure, 502 bad gateway, 503 unavailable (include
Retry-After), 504 gateway timeout.
Do not return 200 with an error body: it breaks monitoring, retries and generic clients. Reserve 5xx for genuine server faults so alerts stay meaningful. Pick 400 for malformed requests but 422 for well-formed input that fails business validation, and document your mapping.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.