HTTP Status Codes Directory & Guide
Search and inspect all standard HTTP status codes. Review RFC specifications, copy sample requests, and follow developer checklists to resolve client and server errors.
OK
Standard: RFC 9110 §15.3.1
Specification & RFC Meaning
The payload sent in a 200 response depends on the request method: GET returns the requested entity; POST returns a description of or result of the action; HEAD returns identical headers with no body.
Example Curl Trigger / Request
curl -i https://api.example.com/v1/usersDeveloper Troubleshooting Checklist
- ✓Verify that the response Content-Type matches the serialized body (e.g. application/json).
- ✓Do not return 200 OK with an error message inside the body (avoid GraphQL anti-pattern for REST APIs).
REST API Status Code Conventions & Best Practices
01.Success Codes: 200 vs 201 vs 204
In RESTful API design, choosing the correct 2xx response code signals the exact outcome to the client:
- 200 OK: Standard for successful
GETreads, updates where the modified entity is returned in the payload, or actions producing an immediate result. - 201 Created: Mandatory when a new resource is inserted via
POSTorPUT. Always supply aLocationheader with the URI of the created item. - 204 No Content: Standard for successful
DELETErequests. Do not include any body in a 204 response.
02.Redirects: 301 vs 302 vs 307 vs 308
Redirect codes control both client caching and whether HTTP methods are safely preserved:
- 301 Moved Permanently: Legacy permanent redirect. Many web browsers historically rewrote
POSTtoGET. - 308 Permanent Redirect: Modern RFC standard. Guarantees that the HTTP method and request body remain unchanged (a
POSTremains aPOST). - 307 Temporary Redirect: Temporary equivalent of 308 that also prevents method mutation, making it the safest choice for redirecting API mutations.
03.Auth Errors: 401 Unauthorized vs 403 Forbidden
These two codes are often conflated, but they represent distinctly different authorization phases:
- 401 Unauthorized: Means Unauthenticated. The client has either provided no credentials or an expired token. The server must provide a
WWW-Authenticatechallenge header. - 403 Forbidden: The client is authenticated and their identity is confirmed, but their role or scope is insufficient to access the resource. Repeating the request with the same token will never succeed.
04.Handling 429 Too Many Requests & 503 Overloads
Robust API clients should never retry failed requests in a tight loop. Instead:
- Respect Retry-After: If the server responds with 429 or 503 containing a
Retry-After: 30header, wait that exact duration before attempting a retry. - Exponential Backoff + Jitter: When no header is present, scale retry pauses exponentially (e.g., 1s, 2s, 4s, 8s) combined with random jitter to prevent a "thundering herd" from taking down the recovering server.