APIs
REST modeling: 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 material stick.
Reconstruct the unit’s core moves — nouns vs verbs, the non-CRUD transition patterns, nesting limits, the representation/resource split, idempotency, and HATEOAS pragmatics — without looking back at the lesson.
- 01Why is 'the verb lives in the HTTP method, not the URL' the core move of REST, and what do you lose the moment you write POST /createOrder?
- 02Real domains have actions that are not create/read/update/delete — cancel, publish, refund. Give the two clean patterns and the anti-pattern to avoid.
- 03What is the senior rule of thumb for nesting depth, and what two problems does deep nesting cause?
- 04Distinguish a resource from a representation, and explain why 'don't serialize DB rows directly' is the highest-leverage decision in API design.
- 05Define idempotency, say which HTTP methods are idempotent, and explain how to make a POST create safely retryable.
- 06What is HATEOAS, why is it the theoretical endgame, and why does almost nobody ship it?
If you could reconstruct each answer from memory, you hold the unit’s spine: model nouns and keep the verb in the method; non-CRUD transitions become guarded action or transition resources, never a writable status field; nest shallow and use expansion to defeat chatty screens; serialize through a mapping layer so the representation is a contract you own rather than your DB schema; POST is not idempotent, so use idempotency keys for safe retries; and HATEOAS is the elegant theory that level-2 REST, what almost everyone ships, usually does without.