10 parts · 16 chapters

API Design and Contracts

The backend mirror of Design Systems: an API is a product whose users are other engineers, and like a design system it needs a vocabulary, consistency, documentation and governance. A bad API decision outlives the team that made it, because clients depend on it for years.

Ten parts: resource modelling; REST done properly; gRPC and Protobuf; GraphQL on the server; events and AsyncAPI; errors, pagination and filtering; versioning and deprecation; idempotency keys and retries; SDK generation and developer experience; and contract testing with API governance.

resource modelling · REST properly · gRPC and Protobuf · GraphQL on the server · events and AsyncAPI · errors and pagination · versioning · idempotency and retries · SDKs and DX · contract testing and governancesenior → staff · backend engineers designing public, partner or internal APIs
modellingResources from the domain, not from tables; nouns, states and actions.
stylesREST, gRPC, GraphQL and events, and when each fits.
consistencyErrors, pagination, filtering, naming and formats, the same everywhere.
evolutionAdditive change, versioning, deprecation and sunset.
reliabilityIdempotency keys, retries, rate limit headers.
governanceLinting, contract tests, review and the API style guide.
Built on Node and Backend System DesignNode course part 7 introduced API design rules; Ledgers part 2 covers idempotency in depth; Auth covers API security.