API Design Roadmap

Nine levels from contract fundamentals through errors, idempotency and styles to real-time APIs, compatibility, governance and production evolution.

0 / 94 roadmap lessons mastered0%
  1. 1

    Level 1 · Think in contracts, not endpoints

    An 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.

    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
  2. 2

    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.

    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
    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
  3. 3

    Level 3 · Survive retries and concurrent writers

    The network loses responses, so clients retry; two clients edit the same resource, so writes collide. Idempotency keys, versions with If-Match, and explicit state transitions keep both survivable.

    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
  4. 4

    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.

    Which API Style Should I Use?
    REST as a Practical Style
    The "REST Purity" Anti-Pattern
    RPC: Operation-Oriented Contracts
    gRPC: Schema, Codegen and Streams
    GraphQL: Client-Shaped Queries Over One Schema
    What GraphQL Costs
    Backend for Frontend
    Batch APIs and Partial Failure
  5. 5

    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.

    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
  6. 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.

    Versioning: What a Version Even Promises
    Backward Compatibility: The Real Rules
    Enum Evolution: The New Value That Broke Old Clients
    Removing Fields Without Removing Consumers
    Deprecation as a Process, Not a Label
    Consumer-Driven Evolution: Telemetry Before Breakage
  7. 7

    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.

    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
  8. 8

    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.

    Schema-First vs Code-First
    OpenAPI: Describing the Contract, Not Designing It
    Documentation Is Part of the Contract
    SDK Design: The Contract's User Interface
    Testing the Contract, Not Just the Code
  9. 9

    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.

    API Migration: Running the Change End to End
    Composed APIs: Aggregating Other Services
    The Gateway as Policy Boundary