Design an HTTP API that survives contact with clients: resource-shaped URLs, methods that mean something, status codes a client can act on, versioning that does not break existing callers, and pagination that scales.
An API is a promise, and most API failures are promises kept badly rather than code that crashed. A client that gets 200 with an error message in the body, or 404 for an item that exists, or a list endpoint that times out at 50,000 rows, has learned nothing useful and will keep making the same request. This course treats the HTTP layer as a design surface rather than a transport. It starts from the constraints that make REST REST — resources, a uniform interface, statelessness — and is honest about which of them are conventions you agree on rather than laws the protocol enforces. It then covers the parts that decide whether an API is usable in production: designing URLs that name resources, choosing status codes so a client can branch without parsing prose, writing error bodies that are as designed as success bodies, versioning with a rule for what counts as breaking, and pagination that does not degrade into OFFSET 100000. By the end you can take a feature request and turn it into a contract: the resources, the methods, the status codes, the error shapes, the pagination scheme, and a written compatibility policy. That artifact is what gets reviewed, and it is the deliverable this course grades.