{
    "slug": "api_versioning",
    "term": "API Versioning",
    "category": "api_design",
    "difficulty": "intermediate",
    "short": "Strategies for evolving an API without breaking existing consumers — URI versioning, header versioning, and content negotiation.",
    "long": "URI versioning (/v1/, /v2/) is the most visible and cache-friendly approach. Header versioning (Accept: application/vnd.api+json;version=2) keeps URLs clean but is harder to test in a browser. Content negotiation uses the Accept header's MIME type. Semantic versioning applied to APIs: breaking changes require a major version bump. Deprecation policy: announce deprecation, support both versions for a transition period, then remove. Never silently change a response field — add new fields alongside old ones.",
    "aliases": [
        "REST API versioning",
        "API version strategy",
        "/v1/ API",
        "header versioning"
    ],
    "tags": [
        "api_design",
        "architecture"
    ],
    "misconception": "Adding a field to an API response is non-breaking. Consumers that deserialise into typed objects may fail on unexpected fields. Always version even additive changes in strict environments.",
    "why_it_matters": "A breaking API change without versioning forces all consumers to update simultaneously — often impossible in a microservices or public API context. Versioning gives consumers time to migrate.",
    "common_mistakes": [
        "Not versioning from day one — retrofitting versioning breaks all existing URL references.",
        "Deprecating a version without announcing a timeline and giving consumers adequate migration time.",
        "Using dates as version identifiers (2024-01-01) — hard to compare and communicate breaking vs non-breaking changes."
    ],
    "when_to_use": [
        "Version your API from the first public release — never ship an unversioned public API.",
        "Use URI versioning for public APIs — it is explicit, cacheable, and easy to route."
    ],
    "avoid_when": [
        "Do not version internal APIs used by a single team — the overhead outweighs the benefit.",
        "Avoid creating a new version for every change — only major breaking changes warrant a new version."
    ],
    "related": [
        "rest_constraints",
        "api_design"
    ],
    "prerequisites": [
        "rest_constraints"
    ],
    "refs": [
        "https://restfulapi.net/versioning/"
    ],
    "bad_code": "// No versioning — any change breaks consumers\nRoute::get('/api/users', [UserController::class, 'index']);\n// Removing a field or changing a response structure breaks all clients silently",
    "good_code": "// URI versioning — simple, explicit, cache-friendly\n// routes/api.php\nRoute::prefix('v1')->group(function () {\n    Route::get('/users', [V1\\UserController::class, 'index']);\n});\nRoute::prefix('v2')->group(function () {\n    Route::get('/users', [V2\\UserController::class, 'index']);\n});\n\n// Add deprecation header on old version\nheader('Deprecation: version=\"v1\", sunset=\"2026-12-31\"');",
    "quick_fix": "Add /v1/ prefix to all API routes from day one — retrofitting versioning after launch is significantly more painful",
    "effort": "medium",
    "created": "2026-03-31",
    "updated": "2026-03-31",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/api_versioning",
        "html_url": "https://codeclaritylab.com/glossary/api_versioning",
        "json_url": "https://codeclaritylab.com/glossary/api_versioning.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[API Versioning](https://codeclaritylab.com/glossary/api_versioning) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/api_versioning"
            }
        }
    }
}