intermediate
REST API design
Model resources, methods, status codes, pagination, filtering, versioning, idempotency, errors, and OpenAPI contracts.
REST API interviews test resource modeling, HTTP semantics, list operations, evolution, idempotency, error shape, and OpenAPI as a reviewed contract.
Subtopics: resources and methods, status codes, pagination/filtering/sorting, versioning and compatibility, idempotency, error response shape, and OpenAPI contracts.
On interviews: design endpoints for a domain noun, pick status codes for validation vs conflicts, and explain safe retries on POST with idempotency keys.
Common pitfalls: verbs in URLs for everything, 200 for errors, breaking list clients on sort changes, and OpenAPI that diverges from production.
The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.
Checklist:
- Model nouns as resources with clear method semantics.
- Use status codes consistently with machine-readable errors.
- Prefer cursor pagination for large mutable lists.
- Version additively; document deprecation windows.