HTTP methods and status codes

Methods carry semantics beyond routing. Safe methods should not change server state (GET, HEAD, OPTIONS). Idempotent methods produce the same effect when repeated (PUT, DELETE, GET). POST is neither safe nor idempotent — retries need care.

| Code class | Meaning | Examples | |------------|---------|----------| | 2xx | Success | 200 OK, 201 Created, 204 No Content | | 3xx | Redirection | 301 permanent, 302/307 temporary, 304 Not Modified | | 4xx | Client error | 400 validation, 401 unauthenticated, 403 forbidden, 404, 409 conflict, 422, 429 rate limit | | 5xx | Server error | 500 unexpected, 502 bad gateway, 503 unavailable, 504 timeout |

					// Express-style mapping
if (!user) return res.status(401).json({ error: 'unauthenticated' });
if (!allowed) return res.status(403).json({ error: 'forbidden' });
				

On interviews: choose status codes that help clients retry correctly — 429 with Retry-After, 503 for overload, 409 for version conflicts; never return 200 with an error body for APIs.

Common pitfalls: 401 vs 403 confusion; using 404 to hide existence; 500 for validation errors; non-idempotent POST retries creating duplicates without idempotency keys.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• State safety and idempotency per method.
• Map domain errors to precise 4xx codes.
• Reserve 5xx for unexpected server faults.
• Document retry policy per status class.