Resilient REST APIs: The case for Parallel Change
summary
Argues that switching integer policy IDs to nano‑ID strings becomes non‑breaking by adding new fields and running a three‑phase expand migrate contract rollout. Implements APIs in Haskell, generates OpenAPI/Swagger, enforces rules with Spectral in CI, tests with QuickCheck, and measures adoption via Jaeger and Grafana. Claims parallel change reduces client disruption but increases producer maintenance and requires telemetry and clear communication; real outcomes include slower-than-expected client migration and occasional decisions not to deprecate old fields.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:22API evolution challenges
- 8:26Breaking vs backward changes
- 12:19API versioning compared
- 15:06Parallel change solution
- 16:48Expand migrate contract phases
- 22:02Expand phase lessons
- 27:39Tooling for resilient schemas
- 29:23Client migration with observability
- 30:47Contract phase removal
- 31:08Preventing breaking changes
- 35:19Reluctant client migration
- 37:25Parallel change longevity
related talks
40mGive It a REST – Tips for Designing and Consuming Public API’s
35mBroken APIs Break Trust: Tips for Creating and Updating APIs
17mTransforming API Management: A Case Study from Atlassian
57mGive it a REST - Tips for designing and consuming public API's
48mRefactoring of REST API
49mTop REST API Design Pitfalls
44mSeamless Upgrades: Mastering API Compatibility
51mREST beyond the obvious – API design for ever evolving systems