Make your APIs Developer-friendly
summary
Practical checklist for internal APIs: use tooling like optic that documents your entire API in minutes and surfaces every change as a code-review conversation so regressions are visible early, track usage so you discover that about 20% of fields are often unused, and map who depends on which endpoints so planned upgrades give downstream teams time. Prioritize accurate docs, observability, and treating endpoints as human-to-human relationships with shared responsibility and coordinated changes.
AI-written summary · about
chapters (9)
- 0:00Intro
- 1:02Make your APls developer- friendly
- 3:18How to build a better [Digital] Rube Goldberg Machine, and have fun doing it
- 6:30if it is complex, it's collaborative! we need to divide labor because we can't fit all the knowledge in our head, we don't have time, and someone has better infrastructure
- 10:412 constants We're always building tracks APIs & Business is Changing
- 12:20server, client, producer, consumer" "collaborators
- 14:03Is every API documented? Accurately?
- 16:19Do you know when your API behavior changes? Who it might affect?
- 18:13Do you know who uses your API? Their use cases?
related talks
26mBuilding successful API developer programs
33mDesigning Sustainable APIs
35mDocumenting APIs: new era, same craft
26mDesigning Accessible APIs
27mGetting developers hooked on your API
24mDocs for Developers: How to start when everything is hard
37mThe end of the beginning of APIs
49mBuilding Software Better: API Lifecycle Management for Developers