API Design interview question · Most asked
Which HTTP status codes should an API use, and when?
Summary
200 OK, 201 Created (with Location), 202 Accepted (async processing), 204 No Content; 400 Bad Request (malformed), 401 Unauthenticated, 403 Forbidden, 404 Not Found, 409 Conflict, 412 Precondition Failed, 422 Unprocessable Content (validation), 429 Too Many Requests; 500 Internal Error, 502/503/504 for upstream and availability problems.
Longer Answer
Be consistent and don't return 200 with an error body. Pair 4xx/5xx with a structured error body (RFC 9457 Problem Details), and include Retry-After for 429/503.
Key Points
- 2xx success variants
- 4xx client errors
- 5xx server/upstream errors
- No 200-with-error
- Retry-After for 429/503
More most-asked API Design questions
- What makes an API RESTful, and what are good REST design practices?
- Which HTTP methods are safe and idempotent, and why does it matter?
- Compare offset pagination and cursor (keyset) pagination.
- How should you version an API?
- How do idempotency keys work for POST requests?
- When would you choose GraphQL over REST, or gRPC over both?