Give it a REST - Tips for designing and consuming public API's
summary
Huddle spends five years evolving a public HTTP API to support microservices, async work and clients on web, iOS, Android, Windows and OS X. Concrete patterns include a progress endpoint (POST → 202 with a status URI), BFF (backend-for-frontends) facades (Python/Node) to preserve old contracts, rate limiting with 429 + Retry-After, graceful deprecation with six months notice, and caching via last-modified/304 and ETags. Real failures: a BFF over-emits Last-Modified causing an iOS client to make 21 calls, and a desktop app crashes from deserializing an unexpected personal-website URI; mitigations include stricter headers, child “mini‑put” resources, and server-side ping/pong checks.
AI-written summary · about
chapters (23)
- 0:00Intro
- 2:30Is that really REST?
- 6:13Anatomy of a REST request
- 7:57Anatomy of a REST response
- 10:07API design - where do you start?
- 12:10An API is a contract
- 14:08Versioning an API
- 15:31Extending an API
- 17:51How do we introduce breaking changes?
- 19:33Elegant deprecation
- 21:56BFF - for compatibility and tailoring
- 24:17Using links to construct a user interface
- 25:23Hypermedia UI (consumer/publisher)
- 27:33Caching - 304 Not Modified
- 30:05Last-Modified header (producer)
- 31:40Rate limiting - 429 Too Many Requests
- 33:43Async and REST
- 38:48Updating FileRequest status
- 40:41Over consuming (consumer)
- 43:01Enumerated values (consumer)
- 44:30Relying on link order (consumer)
- 45:45Be specific (consumer)
- 48:24Resources
related talks
57mGive it a REST - Tips for designing and consuming public API's
40mGive It a REST – Tips for Designing and Consuming Public API’s
35mBuilding Your API for Longevity
01h 04mThe Rest of ReST
46mLet’s have some effective REST!
50mThe Fashion for REST - Creating Beautiful APIs
50mWhat every developer should know about REST
42mLet’s Have Some Effective REST!