How to Approach Retroactive API Versioning
summary
A company-wide evaluation at Typeform tests retroactive API versioning by walking a five-person group through concrete choices: semantic vs calendar versioning, how clients specify versions (URL header query param or auto-pin), and internal resolution via shim transform layer or full deployed app versions. The team prototypes using Istio and considers GraphQL but finds no lightweight external tool, calculates high maintenance cost, and decides not to implement versioning yet because breaking-change plans and deprecation channels are absent.
AI-written summary · about
chapters (10)
- 0:00Start
- 2:20What is API versioning?
- 4:41Why is API versioning helpful?
- 5:25Deprecate old endpoints.
- 6:10What are some strategies for API versioning?
- 6:52Version each endpoint separately.
- 12:07What are some downsides of API versioning?
- 12:37Decide internal implementation for versioning
- 15:02How do the versions get resolved internally?
- 20:05CONCLUSION
related talks
50mAPI Versioning for REST: In Real Life, How Do We Do It?
48mSavoir vivre for applications - a few words on API versioning
51mAPI Versioning In Spring Framework 7
59mFuture Proof with ASP.NET Core API Versioning
19mVersioning strategy for a complex internal API
35mVersioning in a Microservice Architecture
30mBreaking backwards compatibility: The easy way!
23mBackward Compatibility by Default: Keeping API Consumer Trust Intact