Practise vocabulary for classifying API changes: breaking vs. backward-compatible, semantic versioning, deprecation, and migration language.
0 / 5 completed
1 / 5
Removing a required field from an API response is classified as a ___ change.
Removing a required field is a breaking change — existing consumers that depend on this field will fail when they receive a response without it. Breaking changes require a major version bump or coordinated consumer migration.
2 / 5
Adding a new optional field to an API response (that existing consumers don't use) is classified as an ___ change.
An additive change adds new optional content without removing or modifying existing content. Existing consumers are unaffected because they ignore unknown fields (when properly implemented).
3 / 5
In semantic versioning for APIs, a ___ version bump signals that the API change is backward-incompatible and consumers must update.
In SemVer applied to APIs: Major version = breaking changes, Minor version = new backward-compatible features, Patch = backward-compatible bug fixes. A major bump (v1 → v2) signals consumers must update.
4 / 5
A field marked as ___ in an API signals that consumers should stop using it and migrate to a replacement, before it's removed in a future version.
Deprecation marks a field or endpoint as planned for removal. It gives consumers a grace period to migrate. Good deprecation practice includes: the field still works, a migration guide exists, and a removal timeline is communicated.
5 / 5
The preferred versioning strategy that exposes the API version in the URL path (e.g., /api/v2/users) is called ___ versioning.
URI versioning (e.g., /api/v2/) makes the version explicit and visible in every request. It's the most widely used strategy because it's easy to route, debug, and document, though it duplicates URLs across versions.