RESTful APIs

Resource-oriented API design.

RESTful APIs is taught here in 14 lessons, running from Resource modelling and methods through to REST compared with GraphQL, gRPC and tRPC. Each lesson takes one topic, shows the working code, and links onward to the next, so the course can be read straight through in order.

Lessons

1. Resource modelling and methodsDesigning URLs around resources, mapping actions to HTTP methods, and the idempotency guarantees clients depend on.
2. Status codes, pagination and filteringThe status codes an API should return, offset versus cursor pagination, and the query parameters clients expect for filtering, sorting and fields.
3. Versioning and error shapesHow to evolve an API without breaking clients, and the error format that makes failures actionable.
4. Content negotiation and media typesAccept and Content-Type are how a client and a server agree on representation, and getting the failure codes right makes an API predictable.
5. Authentication and authorisationChoosing between API keys, OAuth 2.0 and signed tokens, and validating what you accept rather than trusting what it claims.
6. Caching with ETag and Cache-ControlValidators and directives let a client skip a body it already has, which is the cheapest performance work available on any API.
7. Idempotency, retries and rate limitingNetworks fail after the server has done the work. Idempotency keys make a retried write safe, and honest rate limits make clients behave.
8. Handling uploads and binary payloadsSmall files can go through the API. Large ones should not, and pre-signed URLs move the bytes without touching your application servers.
9. Hypermedia and the Richardson maturity modelHypermedia is the part of REST most APIs skip. It has a real cost, and a real payoff when clients must evolve alongside the server.
10. Long-running operations, webhooks and bulk endpointsSome work cannot finish inside an HTTP request. Returning 202 with a status resource is the pattern that keeps clients and servers honest.
11. Documenting APIs with OpenAPIA specification that is generated from code drifts less; one written by hand stays readable. The useful answer is usually both, with a lint gate.
12. Testing and contract testing REST APIsTest the failures as carefully as the happy path, and let a contract test catch the change that would break a client you do not control.
13. Securing REST APIs beyond authenticationMost breaches in real APIs are not broken crypto. They are CORS misconfiguration, mass assignment and a server that fetches a URL you gave it.
14. REST compared with GraphQL, gRPC and tRPCPick the protocol that matches the shape of the data and the shape of the clients, and expect to run more than one.

More in XML & Web Services

XML XPath XSLT SOAP RSS & Atom

FAQ