APIs
APIs: multiple-choice review
Crux Multiple-choice synthesis across the APIs track — resource modeling, the status-code retry contract, cursor pagination, OpenAPI break diffs, gRPC-vs-REST, and rate-limit headers as one connected design.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole track. Each one mirrors a review decision on a real public API — not a definition to recite, but a place where one weak link load-bears the next.
Goal
Confirm you can trace the cascade end to end: how resource modeling sets up honest status codes, how status codes drive client retries, how pagination and the OpenAPI contract keep both correct under load, and where protocol and rate limits fit.
Quiz
Completed
A team modeled POST /chargeCard instead of a payments resource. Months later they get duplicate charges. What is the root link in the cascade?
Heads-up The rate limit is the last guardrail, not the root. Even with a perfect limit, a verb-shaped endpoint returning 200 for duplicates still double-charges on the first retry. The cascade starts at modeling.
Heads-up PUT is idempotent only for full replacement of a known resource id; creating a payment is a POST. Idempotency for creation comes from an Idempotency-Key, not from swapping the method.
Heads-up Mobile networks fail constantly; banning retries trades double-writes for lost writes. The fix is an addressable resource plus an idempotency key that makes the retry safe.
Quiz
Completed
Which statement best captures why the HTTP status code is a contract, not decoration?
Heads-up Reverse priority. Generic clients and SDKs branch on the status code and headers without parsing your body; the code is the machine-readable part of the contract.
Heads-up Returning 200 with an in-body error is the classic anti-pattern: retry logic, caches, and monitoring all read the 200 as success and never see the failure. The code must reflect the outcome.
Heads-up 5xx is safe to retry only when the operation is idempotent. Retrying a non-idempotent POST on a 5xx that landed after the write is exactly how you double-charge.
Quiz
Completed
An endpoint returns a 2M-row list, browsed live, using OFFSET/LIMIT, and deep pages are getting slow and occasionally skip rows. Best structural fix?
Heads-up An index helps the ORDER BY, but OFFSET 100000 still forces the DB to scan and discard 100k rows on every deep page. Cost grows with depth regardless of the index.
Heads-up Caching a live paginated list serves stale, drifting pages and does nothing for the long tail of unique deep pages. Keyset removes the slow path structurally instead of papering over it.
Heads-up That hides the symptom and breaks legitimate deep browsing. Cursor pagination eliminates the slow part rather than fencing it off.
Quiz
Completed
A deploy renamed the error envelope field from `message` to `detail` and tightened a status enum. CI was green and clients broke in production. What was missing, and which changes were the problem?
Heads-up Backward compatibility means an unmodified old client still works. Renaming a field and tightening an enum break that by definition — the producer broke the contract, not the consumer.
Heads-up Renaming (removing the old name) and tightening validation are breaking, not additive. Additive means adding an optional field or a new enum value the client can ignore.
Heads-up Tests against the old shape stayed green precisely because they were not regenerated from the spec. The fix is a machine diff of the new spec against the old, not removing tests.
Quiz
Completed
A teammate wants the public API to be gRPC because benchmarks show ~77% lower latency, ~10x smaller messages, and higher throughput. How should a senior reason about it?
Heads-up Raw latency is not the constraint a public API is optimized for. Over the public edge, gRPC kills discoverability, breaks curl/browser access, and raises onboarding friction for external developers.
Heads-up At 40k req/s with tiny payloads and streaming, JSON-over-HTTP burns extra CPU, memory, and bandwidth and lacks first-class streaming. The internal hop is the one place gRPC's numbers genuinely matter.
Heads-up GraphQL solves client-shaped over/under-fetching; it does not address the high-throughput internal streaming hop and adds query-complexity and caching headaches at the public edge. It is a different tool, not a drop-in.
Quiz
Completed
A retry storm at peak turns into an outage: tens of thousands of duplicate writes per second hit the database. Which control would have contained it, and how should it behave?
Heads-up A bare 503 with no Retry-After leaves clients to guess; many retry immediately and amplify the storm. The throttle must tell clients when to come back via Retry-After.
Heads-up Silently dropping looks like a network failure, which triggers more retries and hides the limit from the client entirely. A 429 with Retry-After is an explicit, machine-readable backoff signal.
Heads-up Without Retry-After clients fall back to their own (often aggressive or fixed) backoff, and the documented quota becomes guesswork. The header is what makes the backoff cooperative.
Recap
The track is one chain, not a checklist. Resource modeling (nouns, non-CRUD actions as sub-resources) decides whether status codes can be honest; status codes are a machine-readable retry contract (201/409/429, Idempotency-Key on unsafe writes, Retry-After on throttles); cursor pagination keeps large/live reads flat and stable; spec-first OpenAPI with a CI break diff stops silent drift; versioning evolves additively and bumps only on real breaks with a Sunset policy; protocol is an orthogonal axis (REST at the edge, gRPC internal); and rate limits with 429 + Retry-After keep a retry storm from becoming an outage. Review the cascade, because each link load-bears the next.