Give it a REST - Tips for designing and consuming public API's
summary
Huddle describes practical REST lessons from a public API used by ~30 customers while migrating from a monolith to microservices: use BFF facades to keep old URIs working, expose progress endpoints for long jobs (202 + pollable status), enforce rate limits like 50 calls a minute, and monitor which clients hit which endpoints. Cache with Last-Modified/ETag (implemented via Redis) to return 304 fast, avoid coupling APIs to DB schemas, give six months for deprecation, and fix brittle clients instead of breaking users.
AI-written summary · about
chapters (23)
- 0:00Intro
- 2:13Is that really REST?
- 4:58Anatomy of a REST request
- 6:42Anatomy of a REST response
- 10:01API design - where do you start?
- 12:21An API is a contract
- 14:14Versioning an API
- 15:54Extending an API
- 18:34How do we introduce breaking changes?
- 20:06Elegant deprecation
- 22:13BFF - for compatibility and tailoring
- 25:15Using links to construct a user interface
- 26:38Hypermedia UI (consumer/publisher)
- 28:43Caching - 304 Not Modified
- 31:27Last-Modified header (producer)
- 33:24Rate limiting - 429 Too Many Requests
- 35:07Async and REST
- 37:27Mini PUT/POST.../status example
- 39:04Updating FileRequest status
- 40:34Over consuming (consumer)
- 42:33Enumerated values (consumer)
- 45:15Be specific (consumer)
- 48:44Resources
related talks
40mGive It a REST – Tips for Designing and Consuming Public API’s
55mGive it a REST - Tips for designing and consuming public API's
42mLet’s Have Some Effective REST!
35mBuilding Your API for Longevity
46mLet’s have some effective REST!
37mREST, for real!
48mRefactoring of REST API
42mREST API design good practices