Backward Compatibility by Default: Keeping API Consumer Trust Intact
summary
A 2024 study of Android plus 681 open-source apps finds on average two API field compatibility issues per change and a 3.5‑month fix time, so the talk shows a spec-first workflow using Specmatic backward-compat command to catch regressions early. Examples: adding optional size is compatible, making offset mandatory breaks clients, replacing 201 with 202 or int IDs with string UUIDs creates wide incompatibilities. The demo uses pre-commit hooks, a CI gate and a version bump to /v2 to manage inevitable breaking changes.
AI-written summary · about
chapters (14)
- 0:00API compatibility challenges
- 1:33Specmatic for API issues
- 3:42Pagination changes demo
- 6:32Breaking changes detection
- 8:58Data type changes impact
- 10:43Response structure changes
- 12:05Fixing incompatible specs
- 13:51Necessary breaking changes
- 16:19Reviewing changes
- 17:22Alternatives to breaking changes
- 18:28Git hooks and CI checks
- 21:44Specmatic for multiple APIs
- 22:27Early compatibility detection
- 23:00Q&A
related talks
34mDesigning a Compatible API — Genius Without Villainy
53mAPI Standards 2.0
25mHow to Approach Retroactive API Versioning
40mFuture-Proofing Java: The Art of Crafting Resilient APIs
15mAutomotive Grade APIs – designing for longevity
32mHow to successfully shift from app development to SDK development
39mResilient REST APIs: The case for Parallel Change
48mSavoir vivre for applications - a few words on API versioning