APIs
An API (Application Programming Interface) is a contract: a defined set of requests a client is allowed to make of a service, and the responses it can expect back, without needing to know anything about how that service is actually implemented. It's the same idea as a function signature, just exposed across a network boundary instead of within one process — and that network boundary is what turns "just call a function" into an entire module's worth of design decisions.
API Gateway
An API gateway is a single entry point that sits in front of a collection of backend services and handles the concerns every one of them would otherwise have to duplicate: authentication, rate limiting, request routing, and response aggregation. Instead of a mobile client knowing about (and directly calling) a dozen individual services, it talks to one gateway, and the gateway figures out where each request actually needs to go.
REST vs GraphQL
REST and GraphQL are two different answers to the same question: how should an API expose data to a client? REST models an API as a set of resources, each with its own URL; GraphQL models an API as a single queryable graph, where the client describes exactly what shape of data it wants in one request. Neither is a networking protocol on its own — both typically ride on top of HTTP/HTTPS — the difference is entirely in how the request/response contract is structured.
WebSockets
Every API pattern covered so far in this module shares one assumption: the client asks, the server answers, and the connection's job is done. WebSockets break that assumption on purpose — they establish a single, long-lived connection over which either side can send a message to the other, at any time, without the other side having asked first. That's the difference between an ordering system where you have to keep asking "is it ready yet?" and one where the kitchen taps you on the shoulder the moment it is.
Webhooks
A webhook inverts the usual direction of an API call. Instead of your service repeatedly asking another service "has anything happened yet?", you register a URL with that service once, and it sends an HTTP request to you the moment something actually happens — a payment clears, a file finishes uploading, a build completes. It's "don't call us, we'll call you," implemented as a plain HTTP POST.
Idempotency
An operation is idempotent if performing it multiple times has exactly the same effect as performing it once. Setting a light switch to "on" is idempotent — flipping it to "on" five times leaves it exactly as on as flipping it once. Pressing "add one item to cart" is not — pressing it five times adds five items. This one property turns out to be one of the most load-bearing concepts in distributed API design, because it's the difference between "safe to retry" and "dangerous to retry."
Rate Limiting
Rate limiting caps how many requests a client can make in a given window of time, and rejects the rest — typically with an HTTP 429 Too Many Requests — before they ever reach the actual business logic. It's a deliberately blunt tool: rather than trying to make every request cheap, it accepts that some requests will be turned away, in exchange for guaranteeing the system as a whole stays up for everyone else.
API Design
Every lesson in this module has covered one piece of an API in isolation — what it is, what sits in front of it, how it shapes data, how it stays safe under retries and load. Good API design is what happens when those pieces are chosen deliberately and made to work together, instead of accumulating ad hoc as a service grows. It's less about any single rule and more about a handful of habits that keep an API predictable to use and safe to evolve.