Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why can adding a new OPTIONAL field to an existing API response generally be done within the same API version, without requiring a new major version?
💻 Code Challenge | +75 XP
Implement Deprecation and Sunset response headers on a deprecated API endpoint, including a Link header pointing to migration documentation, and write a written definition distinguishing breaking from non-breaking changes for your API.
A company removed a deprecated API version after its planned sunset date, only to discover via a support escalation that a major partner integration was still actively using it and broke immediately. Reorder the steps that should have prevented this.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Removing a deprecated API version based purely on a calendar date, without checking actual current usage
// Risky: removed purely by calendar, no traffic check
// if (Date.now() > sunsetDate) removeV1Endpoints();
// Correct: verify actual usage first
const stillInUse = await getMetric("api_requests", { version: "v1" });
if (stillInUse > 0) investigateBeforeRemoving();The Solution //
A consumer who never saw or acted on a deprecation notice (a partner's integration nobody remembered to update, or a deprecation notice that went to the wrong contact) can still be actively using a version scheduled for removal — removing it purely by calendar date without confirming real traffic has actually dropped to zero risks a breaking, unexpected outage for that consumer.
The Error //
Treating any change to an API response as automatically requiring a new version, with no distinction between breaking and non-breaking changes
// Unnecessary: a new version for a purely additive, non-breaking change
// Correct: adding an optional field stays within the SAME version
// { "id": 1, "total": 100, "currency": "USD" } — v1, unchanged, non-breakingThe Solution //
This creates unnecessary version proliferation and operational overhead — most natural API evolution (adding an optional field, adding a new endpoint) doesn't break existing clients and can safely happen within the same version, reserving new versions specifically for genuinely breaking changes.