Good API design
summary
Argues that the single worst mistake is no API or an accidental one that exposes the database, and advises providing a documented, runnable examples API from day one. Recommends use REST and JSON for web services, build a layered core API so clients never depend on internals, and design for performance with batch requests (e.g., request ten years of player data in one call to avoid 10 round trips). Pushes phased versioning, a data dictionary, and writing real client scripts to validate the design.
AI-written summary · about
chapters (26)
- 0:00Intro
- 2:07When you do software
- 5:52What's an API
- 7:16What's an Anti-pattern
- 8:45API Design Antipatterns
- 9:46More kinds of APIDAS
- 10:56The very worst APIDA
- 12:58Why "no API" is bad
- 17:13What to do instead
- 21:18The accidental API
- 23:02Why "no design" is bad API
- 24:27Wtdi: Think
- 26:29Wtdi: Forget
- 29:40A worst-case bad API...
- 30:56Too many cooks APIS
- 35:31API Transition: must plan!
- 37:22Fear of commitment
- 37:40The "Let's do both!" APIDA
- 38:32gmpy as a bad example
- 39:18To decide is human
- 40:25Inconsistency APIDAS
- 41:18Why inconsistency?
- 44:40Prog.language support
- 47:00Standard-protocol support
- 48:35Debugging errors, docs
- 50:23Performance issues
related talks
52mDesigning and Implementing REST APIs For the Long Haul
21mScaling API Design
18mBuild a terrible API for people you hate
51mTop 10 Rest API Design Pitfalls
27mBuilding Great Web APIs
01h 36mThe Most Important API Design Guideline - No, It's Not That One
27mAvoid These API Design Mistakes for Better Business Integration
47mAPI Design Principles