APIs
Status codes: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the distinctions stick when you are choosing a code under pressure.
Reconstruct the unit’s spine without looking back: the class-as-machine-instruction model, the 4xx/5xx ownership split, why 200-with-error-body is the cardinal sin, the idempotency retry trap, and the Retry-After ordering.
- 01Why is the first digit of a status code a machine instruction, and which machines branch on it before any human reads the response?
- 02Explain the 4xx-vs-5xx ownership split and why it is the load-bearing distinction for retries.
- 03Why is returning 200 OK with an error object in the body the cardinal sin, and what specifically breaks?
- 04Walk through the retry decision including the idempotency trap on a timed-out write.
- 05Give the Retry-After ordering for 429 and 503, and why instant retries are dangerous.
- 06Distinguish 401 vs 403 and 400 vs 422, and say what the client should fix in each case.
If you reconstructed each answer from memory, you hold the unit’s spine: the class is a machine instruction read by caches, dashboards, and retry loops; 4xx is the client’s fault (don’t retry) and 5xx is the server’s (maybe retry), with 429 the retryable 4xx exception; 200-with-error-body is the cardinal sin because it blinds every machine; the idempotency trap turns a retried 504 POST into a double charge unless you reconcile or send an idempotency key; Retry-After is honoured before backoff with jitter; and 401/400 versus 403/422 tell the client whether to re-auth/fix-shape or stop/fix-data.