APIs
REST modeling: multiple-choice review
Crux Multiple-choice synthesis across the REST-modeling unit: nouns vs verbs, non-CRUD transitions, nesting depth, representation vs resource, idempotency, and HATEOAS pragmatics.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a design decision you make at a whiteboard or in a PR review — not a definition to recite, but a tradeoff to defend when a teammate pushes back.
Goal
Confirm you can connect resource modeling, non-CRUD transitions, nesting depth, the representation/resource split, idempotency, and HATEOAS pragmatics — the synthesis the lesson built toward.
Quiz
Completed
A teammate proposes GET /getOpenOrders and POST /createOrder as your two new endpoints. What is the most precise objection?
Heads-up Length is cosmetic. The real defect is that the URL carries a verb the HTTP method already expresses — that is RPC-over-HTTP, and it costs you the uniform interface, not a few characters.
Heads-up Reads must stay GET so they are safe and cacheable; making a read a POST hides that it has no side effects. The defect is the verb in the path, not the method choice for the create.
Heads-up Consistency does not redeem an RPC shape. Once the URL names the action, intermediaries and clients can no longer reason about it as a resource, which is the entire point of REST.
Quiz
Completed
You must expose 'cancel an order', a guarded transition with rules (not shipped, not already cancelled). Which model is both RESTful enough and safe?
Heads-up Exposing status as client-writable hands the client the keys to the state machine: it can jump to any state, skip the cancellation rules, and corrupt order state. The transition must be guarded server-side.
Heads-up A cancelled order is not a deleted one; it still happened and carries history. DELETE loses the audit trail and conflates two different lifecycle outcomes.
Heads-up GET must be safe and have no side effects, so a crawler or prefetch could cancel orders. A state-changing action must use POST, never GET.
Quiz
Completed
A dashboard renders /customers/7/projects/3/orders/42/items in nine sequential calls and the path breaks whenever an item moves between orders. What is the senior fix?
Heads-up Caching hides cold-load latency only, invalidation across four nested levels is brutal, and the URLs are still fragile when relationships change. You are optimizing a shape you should flatten.
Heads-up That is an RPC view endpoint, not a resource. Every new screen then wants its own, and you drift back to a verb-per-view API. Field expansion on real resources scales; one endpoint per screen does not.
Heads-up Nesting does express ownership, but past one or two levels it forces chatty N+1 round-trips and fragile encoded paths. Deep ownership does not require deep URLs — reach the resource by its own ID.
Quiz
Completed
Your API serializes ORM rows straight to JSON. Why is adding an explicit mapping layer (DTO/serializer) the highest-leverage decision in the design?
Heads-up Serialization speed is negligible and not the point. The leverage is decoupling: the representation becomes a contract you own instead of an accident of your schema.
Heads-up You can trim columns either way; bandwidth is a side effect. The real win is that clients stop depending on column names, so the database stays refactorable.
Heads-up ORMs serialize relations fine — that is precisely the risk, because they make it trivial to leak the whole schema to the wire. The mapping layer is a deliberate boundary, not a workaround.
Quiz
Completed
A client retries POST /payments because the response timed out, and the customer is charged twice. Which statement about idempotency is correct?
Heads-up Idempotency means repeating a request has the same effect as doing it once. PUT and DELETE qualify; POST does not — two POSTs create two resources unless you add an idempotency key.
Heads-up GET must be safe (no side effects) — it cannot create a payment at all. Safety is not the same as deduplicating a creating request; you need an idempotency key on the POST.
Heads-up PATCH is not guaranteed idempotent either (e.g. an 'increment by 1' patch), and a create is not an update. The mechanism that prevents the duplicate is the idempotency key, not the method label.
Quiz
Completed
A purist blocks your PR because the responses do not carry hypermedia links (HATEOAS). How should a senior weigh this?
Heads-up Almost all production 'REST' APIs are level-2 Richardson with no hypermedia. HATEOAS is valuable in large hypermedia-native ecosystems but rarely worth the cost elsewhere — its absence does not disqualify the design.
Heads-up It is not obsolete — it genuinely decouples clients from URL structure where clients consume links. It is underused, not wrong; know what it buys and when it pays for itself.
Heads-up Links only help clients that actually follow them at runtime. Clients that hardcoded URLs still break; hypermedia is a discipline both sides must adopt, not a free compatibility switch.
Recap
The through-line: a REST API models nouns the client needs, with the verb in the HTTP method, filtering and paging in query params, and non-CRUD transitions as guarded action or transition resources — never a client-writable status field. Keep nesting shallow and use expansion to kill chatty screens. Serialize through a mapping layer so the representation is a contract you own, not your DB schema. Know that POST is not idempotent (use idempotency keys for safe retries) and that HATEOAS is the elegant theory level-2 REST rarely needs.