Building Your API for Longevity
summary
Thinks long term: treat the API as a contract, plan for spec-driven development and mock the surface before writing code, and version only for truly breaking platform changes. Uses concrete tools and practices—RAML/Swagger/API Blueprint for prototypes, Accept/Content-Type headers, correct HTTP codes (201, 304), and HATEOAS / hypermedia links—to avoid costly rewrites; one prototype gets scrapped after months and six figures wasted. Notes scale: ~13,000 public APIs exist and Moft serves ~30% of the Global 500.
AI-written summary · about
chapters (11)
- 0:00Start
- 5:37Thinking things through...
- 7:37What is the purpose of Your API
- 9:18What Type of API Are You Bullding?
- 12:45Problems with Versioning
- 13:44You Need to Version When
- 16:42Hybrid Approach
- 18:58Using RAML You Can
- 20:00The RAML API Designer
- 24:23Most Popular Hypertext Link Specs
- 26:14Use Accept/Content-Type Headers
related talks
27mBuilding Great Web APIs
21mScaling API Design
21mIntroducing The API Lifecycle
49mBuilding Software Better: API Lifecycle Management for Developers
41mThe making of a great API
49mPoor API design is not sustainable.
52mDesigning and Implementing REST APIs For the Long Haul
24mDesigning the APIs for an Internal Set of Services