Question 1

301 vs 302 vs 307 vs 308 — which redirect do I want?

Accepted Answer

301 = permanent, can change method (rare). 302 = temporary, can change method (legacy). 307 = temporary, must preserve method. 308 = permanent, must preserve method. Modern answer: use 308 for permanent, 307 for temporary — they behave consistently across HTTP verbs. Use 301 only when you specifically want the legacy method-changing behavior (usually you don't).

Question 2

What's the right code when validation fails on a POST?

Accepted Answer

400 if the request was malformed (missing fields, wrong types, invalid JSON). 422 Unprocessable Entity if the request parsed correctly but the data doesn't make sense (email is valid JSON but already in use, date is valid but in the past). A lot of APIs conflate these and send 400 for everything — not ideal, but survivable.

Question 3

401 vs 403 — what's the difference?

Accepted Answer

401 means 'you haven't authenticated, and you need to' (missing or invalid token). 403 means 'you've authenticated, but this specific resource is off-limits'. If a user is logged in but hits a page they don't have access to, that's 403. If they're not logged in at all, that's 401.

Question 4

Should I return 200 with an error in the body?

Accepted Answer

Almost never. HTTP status codes exist precisely to communicate outcome at the transport level — that's what caches, monitoring tools, retry logic, and SDKs all key off. Returning 200 with `{error: ...}` means every consumer needs bespoke error detection, and your 5xx alerts go quiet during outages. Use the right code, put details in the body.

Question 5

When is 429 the right response?

Accepted Answer

When you're rate-limiting a client. Usually paired with a `Retry-After` header telling them how long to back off. Common mistake: returning 503 when you really mean 'you hit a rate limit' — 503 is for 'the whole service is overloaded'; 429 is for 'you specifically are going too fast'.

HTTP Status Codes

What is HTTP Status Codes?

Related tools