5 exercises on API backward compatibility vocabulary.
0 / 5 completed
1 / 5
What is a breaking change in an API?
Breaking change: removing a required field, changing a type, or removing an endpoint forces all clients to update simultaneously. Non-breaking changes (adding optional fields, new endpoints) can be deployed without client coordination.
2 / 5
What is the Postel's Law (robustness principle) guideline for API design?
Postel's Law: produce minimal, valid output so receivers aren't surprised, but tolerate extra or unexpected fields in input. Ignoring unknown fields in requests prevents old clients breaking when new fields are added.
3 / 5
What is an additive change?
Additive change: safe because existing clients that do not know about the new field or endpoint continue working. Clients must be coded to ignore unknown fields (be liberal in acceptance) for this to hold.
4 / 5
What is API versioning used for?
API versioning: strategies like URL path (/v2/), header, or query param allow breaking changes to exist alongside old versions. Old versions are maintained for a deprecation window before sunset.
5 / 5
Why is removing an enum value considered a breaking change even if clients "should" handle unknown values?
Enum removal: if clients serialized or matched on that value (e.g., case "PENDING_REVIEW"), removing it breaks their logic. Both sides must coordinate, making it a true breaking change requiring a version bump.