HTTP Status Codes, Success Responses, and Error Signaling
Use HTTP status codes correctly so API consumers can understand the outcome of every request clearly.
Inside this chapter
- Why Status Codes Matter
- Common Success Codes
- Common Client Error Codes
- Common Server Error Codes
- Real Example
Series navigation
Study the chapters in order for the clearest path from REST basics to advanced API design, operations, and production readiness. Use the navigation at the bottom to move smoothly across the full tutorial series.
Why Status Codes Matter
Status codes are a core part of the REST contract. They tell clients whether a request succeeded, failed because of a client mistake, failed because of the server, or requires a different action such as authentication or redirection.
Common Success Codes
200 OKfor successful retrieval or update responses201 Createdwhen a new resource is created204 No Contentwhen success requires no response body
Common Client Error Codes
400 Bad Requestfor invalid input or malformed data401 Unauthorizedwhen authentication is required or invalid403 Forbiddenwhen the user is authenticated but not allowed404 Not Foundwhen the resource does not exist409 Conflictwhen a request conflicts with current resource state422 Unprocessable Entityfor semantic validation errors in many APIs
Common Server Error Codes
500 Internal Server Errorfor unexpected server failures502 Bad Gatewayfor upstream service issues503 Service Unavailableduring overload or maintenance
Real Example
If a user tries to create an account with an invalid email, returning 422 or 400 with a helpful validation payload is much better than returning a generic 500. Clients need accurate signals to build good user experiences.