Master the IT-English vocabulary of versioning APIs between microservices: backward compatibility, breaking changes, deprecation and contract evolution.
0 / 5 completed
1 / 5
A change is described as 'backward compatible'. What does that mean?
A backward-compatible change doesn't break existing clients; they continue to work unmodified.
2 / 5
Removing a required field from a response is a 'breaking change'. Why?
Removing or renaming fields breaks consumers that depend on them, requiring coordinated updates.
3 / 5
A team 'deprecates' the v1 endpoint. What does deprecation signal?
Deprecation marks an API as obsolete and slated for removal, prompting consumers to move off it.
4 / 5
Adding a new optional field is usually safe because?
Additive, optional changes are typically non-breaking since tolerant readers ignore unknown fields.
5 / 5
Which sentence correctly uses 'contract'?
The API contract is the agreed interface; honouring it lets services evolve without breaking each other.