API Design Roadmap
Nine levels in one order, starting at Level 1: think in contracts, not endpoints. Every stage names what it needs first and what you should be able to do before moving on. Progress is stored locally in your browser.
Where to start
API Design
9 stages · 0/94 lessonsHow software exposes stable contracts to other software: resources, HTTP semantics, errors, retries, styles, real-time, evolution and governance.
- Level 1 · Think in contracts, not endpoints
- Level 2 · Design the failure and query surface
- Level 3 · Survive retries and concurrent writers
- Level 4 · Choose a style with open eyes
- Level 5 · Escape request/response when it stops fitting
- Level 6 · Evolve without breaking anyone
- Level 7 · Make the contract secure, fast and observable
- Level 8 · Run an API as a product
- Level 9 · Migrate, compose and govern at scale
- 10/18
Level 1 · Think in contracts, not endpoints
Start hereAn API is a behavioral promise to consumers you may never meet. Start from requirements and consumer tasks, model resources and actions honestly, and learn what HTTP methods and status codes actually guarantee.
Before moving on: Turn a product requirement into a resource model and a set of operations, give each one the HTTP method and status code it deserves, and say what a retrying client or a caching proxy may assume from them.
- What an API Contract Actually Is
- Start With Requirements, Not Endpoints
- Consumer-First Design
- API Granularity and the Chatty API
- Public vs Internal APIs
- API Ownership and the Catalog
- Design Principles Without Commandments
- API Anti-Patterns Field Guide
- From Domain to Resources
- Resource or Action?
- The "Everything Is CRUD" Trap
- HTTP Methods Are Promises
- GET: The Promise of Safety
- POST: More Than Create
- Status Codes Clients Can Branch On
- Request Contracts: Required, Optional, Null and Absent
- Response Contracts Are Not Database Rows
- One Vocabulary: Naming and Consistency
- 20/13
Level 2 · Design the failure and query surface
The error model and the list endpoints are where clients actually live. Build a taxonomy clients can branch on, give field-level validation feedback, and bound every collection before it grows. It comes right after the basics because every later stage returns errors and lists, and retrofitting either is a breaking change.
Before moving on: Write an error contract with machine-readable codes and field-level validation feedback, mark every error as retryable or not, and put cursor pagination on a list endpoint before it grows.
Needs first:Level 1 · Think in contracts, not endpoints- The Error Model: Structure Over Apology
- An Error Taxonomy Clients Can Branch On
- Validation Errors: Feedback, Not Verdicts
- Retryability: Telling Clients What To Do Next
- Partial Failure: When 3 of 5 Succeed
- Over-Fetching and Under-Fetching
- Pagination: Choosing How Lists End
- Offset Pagination: Simple, Jumpable, and Lying Under Writes
- Cursor Pagination: An Opaque Bookmark, Not a Position
- Filtering: An Allowlist With an Index Bill
- Sorting: Determinism or Drift
- Search Is a Different Contract Than Filtering
- Unbounded Collections: The Anti-Pattern With a Fuse
- 30/13
Level 3 · Survive retries and concurrent writers
The network loses responses, so clients retry; two clients edit the same resource, so writes collide. Idempotency: Surviving the Retry keys, versions with
If-Match, and explicit state transitions keep both survivable.Before moving on: Design a payment-style endpoint that survives a lost response and a retry, reject a lost update with an
If-Matchversion, and draw the state machine with the transitions a client may request.Needs first:Level 1 · Think in contracts, not endpointsLevel 2 · Design the failure and query surface- PUT vs PATCH
- DELETE: What Does Gone Mean?
- Conditional Requests: ETags, 304 and 412
- Idempotency: Surviving the Retry
- Idempotency Keys: The Mechanism
- Idempotency vs Deduplication
- Optimistic Concurrency: Versions and If-Match
- The Lost Update, Step by Step
- Consistency as a Contract Clause
- There Is No Transaction Across APIs
- Retries and Timeouts as Contract Guidance
- Resources Have State Machines
- Designing State Transitions
- 40/9
Level 4 · Choose a style with open eyes
REST, RPC, gRPC and GraphQL are tools with prices, not religions. Learn what each buys, what each costs operationally, and how the consumer environment — not fashion — decides; backend-for-frontend and batch endpoints are the two hybrids that usually settle the argument. It waits for the error and query surface because that is what each style shapes differently.
Before moving on: Choose between REST, RPC, gRPC and GraphQL for a given consumer environment and defend the choice by what it costs to run, not by what it is called.
- 50/14
Level 5 · Escape request/response when it stops fitting
Long-running work becomes a job resource, live data becomes a stream, and events to third parties become webhooks — each with delivery, ordering and duplicate semantics the contract must state. Uploads and oversized requests get documented limits here too. Every one of these leans on the idempotency and state-machine rules from Level 3, which is why it comes after them.
Before moving on: Turn a fifteen-minute operation into a job resource, pick SSE, WebSockets or streaming for a live feed, and state a webhook's delivery, retry, ordering and signature semantics.
- Long-Running Operations: 202 and the Job Resource
- The Async Job Pattern
- How the Client Learns the Job Finished
- WebSocket Message Contracts
- Server-Sent Events
- Streaming APIs: Partial Data as a Contract
- Slow Clients and Backpressure
- Webhooks: The Inverted Contract
- Webhook Delivery: States, Retries, Redrive
- Consumer-Side Idempotency
- Webhook Ordering: Assume None
- The Webhook Security Contract
- Large Requests and Documented Limits
- File Upload APIs: Authorize, Upload Directly, Confirm
- 60/6
Level 6 · Evolve without breaking anyone
Versioning is the last resort, not the first move. Learn the additive-safe list, forward-compatible enum handling, and deprecation as a measured process backed by consumer telemetry. It sits after the styles because what counts as a breaking change depends on the style — a proto field number, a GraphQL schema, a JSON body.
Before moving on: Add a field, an optional parameter and an enum member without breaking an old client, and run a deprecation from announcement through consumer telemetry to removal.
- 70/13
Level 7 · Make the contract secure, fast and observable
Where authentication, authorization, scopes and rate limits live in the contract — then the API-shaped performance levers (payload, compression, caching) and the request ids, metrics and logs that keep it debuggable. It needs the error model and conditional requests, because a
429is an error clients branch on and caching is a conditional-request promise.Before moving on: Place authentication, scopes and rate limits in the contract, shrink a response with caching and compression, and follow one request id from a client log to a server metric.
Needs first:Level 2 · Design the failure and query surfaceLevel 3 · Survive retries and concurrent writers- Authentication in the Contract
- Authorization Design in the Contract
- Scopes: Least Privilege as Contract Surface
- API Keys: Identity for Applications
- The Rate-Limit Contract
- Quotas vs Rate Limits
- Caching as a Contract Clause
- API Performance: The Levers You Actually Own
- Payload Size: 20KB, 200KB, 5MB
- Compression: Cheaper Bytes, Not Fewer
- Request IDs: The Contract's Correlation Clause
- API Metrics: Rate, Errors, Duration, Sizes
- API Logging Without Leaking
- 80/5
Level 8 · Run an API as a product
A public API is a product with docs, SDKs, schema governance and contract tests. Schema-first vs code-first, OpenAPI as description rather than design, and testing that catches drift before consumers do.
Before moving on: Publish an OpenAPI description that matches the running service, design an SDK that hides retries and pagination, and write a contract test that catches drift before consumers do.
- 90/3
Level 9 · Migrate, compose and govern at scale
Advanced evolution: moving consumers across a breaking boundary with a compatibility matrix, composing APIs over internal services, and deciding which contract clauses the gateway enforces for every API at once.
Before moving on: Plan a breaking migration with a compatibility matrix and per-consumer telemetry, compose one API over several services, and decide which policies the gateway enforces for every API at once.