Working with HTTP Status Codes

1. Using 200 OK

When	Methods	Body
Successful request returning data	GET, PUT, PATCH, POST (action)	Resource representation

2. Using 201 Created

When	Required Header	Body
Resource successfully created	Location: /resource/{id}	Created resource representation

3. Using 202 Accepted

When	Body	Header
Async processing started	Operation status URL	Location: /operations/{id}

4. Using 204 No Content

When	Body
DELETE success, PUT/PATCH no body to return	Must be empty

5. Using 206 Partial Content

When	Required Headers
Range request (file download resume, video streaming)	Content-Range: bytes 0-499/1234

6. Using 304 Not Modified

When	Body	Triggered By
Cached resource still valid	Empty	If-None-Match matches ETag, or If-Modified-Since not exceeded

7. Using 400 Bad Request

Cause	Body
Malformed JSON, missing required field, invalid syntax	Error details with field-level errors

8. Using 401 Unauthorized

When	Required Header
Missing/invalid/expired credentials	WWW-Authenticate: Bearer realm="api"

9. Using 403 Forbidden

When	Note
Authenticated but lacks permission for resource/action	Do not reveal whether resource exists (use 404 for sensitive cases)

10. Using 404 Not Found

When	Alternative
Resource does not exist	Use 410 Gone for permanently removed

11. Using 405 Method Not Allowed

When	Required Header
Resource exists, method not supported	Allow: GET, POST

12. Using 409 Conflict

When	Examples
State conflict prevents action	Duplicate username, version mismatch (optimistic lock), business rule violation

13. Using 422 Unprocessable Entity

When	Difference from 400
Syntactically valid but semantically invalid (failed validation)	400 = bad syntax; 422 = bad semantics

14. Using 429 Too Many Requests

When	Required Headers
Rate limit exceeded	Retry-After: 60, X-RateLimit-Remaining: 0

15. Using 500 Internal Server Error

When	Body
Unhandled server exception	Generic message + correlation/trace ID; never stack traces in production