Which HTTP status codes should every API developer know?
SHORT ANSWER
Know the families: 2xx success (200, 201, 204), 3xx redirect (301, 304), 4xx client error (400, 401, 403, 404, 409, 429), 5xx server error (500, 502, 503, 504). The code tells clients whether retrying can help.
Explain it simply
Status codes are the first thing a client reads, so using them correctly saves everyone time.
- 200 OK: success with a body. 201 Created: a new resource was made (return its location). 204 No Content: success, nothing to return.
- 301 Moved Permanently, 304 Not Modified (use your cached copy).
- 400 Bad Request: malformed or invalid input.
- 401 Unauthorized: not authenticated (no or bad credentials).
- 403 Forbidden: authenticated but not allowed.
- 404 Not Found.
- 409 Conflict: clashes with current state, such as a duplicate or version conflict.
- 429 Too Many Requests: rate limit hit; often with a Retry-After header.
- 500 Internal Server Error: bug on the server.
- 502 Bad Gateway / 504 Gateway Timeout: an upstream server failed or was too slow.
- 503 Service Unavailable: overloaded or down for maintenance.
Rule of thumb: 4xx means fix the request, so do not retry unchanged; 5xx may be temporary, so retry with backoff.
Example
text
POST /users {"email":"a@x.in"}
-> 201 Created, Location: /users/88
POST /users {"email":"a@x.in"} (again)
-> 409 Conflict (email exists)
GET /users/9999
-> 404 Not FoundWhat to say in the interview
"2xx succeeded, 3xx redirected, 4xx the client erred, 5xx the server erred. I distinguish 401 from 403, use 409 for conflicts and 429 for throttling. Clients should retry 5xx with backoff but not 4xx."