Kapitel 87

API Lifecycle: Versioning, Deprecation und Consumer Management

APIs werden betrieben, nicht nur entwickelt: Versionen, Sunset, Consumer-Kommunikation, Breaking Changes und Compatibility Tests.

API LifecycleVersioningDeprecationConsumers

Warum dieses Thema in Version 5 wichtig ist

Version 5 behandelt API Lifecycle: Versioning, Deprecation und Consumer Management als Senior-Thema. In echten Enterprise-Projekten reicht es nicht, eine Bibliothek einzubauen oder ein Pattern zu kennen. Entscheidend ist, ob die Lösung fachlich begründet, testbar, betreibbar, sicher und langfristig änderbar bleibt.

API Lifecycle: Versioning, Deprecation und Consumer Management - kompakte fachliche SVG-Darstellung
API Lifecycle: Versioning, Deprecation und Consumer Management - kompakte fachliche SVG-Darstellung

Orientierungsrahmen

AspektErklärung
AusgangspunktDas Thema wird als Teil einer produktionsreifen Java-Enterprise-Landschaft betrachtet, nicht als isolierte Technik.
KernfrageWelche fachliche Grenze, Betriebsgrenze oder Integrationsgrenze wird durch API Lifecycle: Versioning, Deprecation und Consumer Management sichtbar?
RisikoScheinbar technische Details erzeugen oft fachliche Nebenwirkungen: Datenverlust, Dopplungen, unklare Ownership, Sicherheitslücken oder hohe Betriebskosten.
NachweisADR, Test, Runbook, Metrik, Trace, Contract, SBOM oder Code-Kommentar muss zeigen, dass die Entscheidung verstanden wurde.
1. EntscheidungsgrenzeWas darf das Team frei entscheiden, was braucht Governance?
2. LaufzeitgrenzeWelche Annahme muss im Betrieb messbar bleiben?
3. Daten-/EventgrenzeWelche Daten werden kopiert, versioniert oder gelöscht?
4. SicherheitsgrenzeWelche Identität, Rolle, Policy oder Zertifikatskette wirkt hier?
5. QualitätsgrenzeWelche Tests schützen die Entscheidung gegen schleichende Erosion?
6. Kosten-/BetriebsgrenzeWelche Kosten, Limits oder Runbooks gehören zum Thema?

Technisches Beispiel

Das Beispiel zeigt absichtlich keine Framework-Magie. Die Regel wird als Java-Objekt formuliert. Dadurch kann sie in Spring Boot, Jakarta EE, Quarkus oder Micronaut verwendet und mit Unit-Tests abgesichert werden.

API Lifecycle: Versioning, Deprecation und Consumer Management - Policy Object
package at.aydinsude.enterprise.v5.sketch;

import java.time.Instant;
import java.util.List;
import java.util.Map;

// Pattern: Policy Object - kapselt eine wiederverwendbare Architekturregel.
// Pattern: Strategy - unterschiedliche Projektsituationen können andere Bewertungen liefern.
public final class ApiLifecyclePolicy {
    public ArchitectureDecision evaluate(ArchitectureContext context) {
        int risk = context.businessCriticality() + context.integrationCount() + context.operationalComplexity();
        String action = risk >= 9 ? "formal-review" : risk >= 5 ? "lightweight-adr" : "team-standard";
        return new ArchitectureDecision(action, risk, Instant.now(), List.of(
                "document trade-offs",
                "add automated evidence",
                "define rollback or recovery path"));
    }

    public record ArchitectureContext(int businessCriticality, int integrationCount, int operationalComplexity, Map<String, String> tags) {}
    public record ArchitectureDecision(String action, int riskScore, Instant decidedAt, List<String> evidence) {}
}

Die gleiche Entscheidung muss im Projekt sichtbar bleiben. Eine kleine YAML- oder Markdown-Dokumentation hilft, Standards zu automatisieren und Ausnahmen sauber zu erklären.

Governance-/Evidence-Skizze
# api-lifecycle-versioning-deprecation-und-consumer-management.yaml
owner: enterprise-architecture
chapter: 87
risk_level: senior
evidence_required:
  - adr
  - architecture-test
  - runbook
  - monitoring-dashboard
review:
  cadence: quarterly
  escalation: architecture-board

Typische Fehlerbilder

Fehler 1: Das Thema wird nur technisch gelöst. Fachliche Auswirkungen, Wiederanlauf, Security und Ownership bleiben unklar.
Fehler 2: Teams bauen Sonderlösungen ohne gemeinsame Standards. Dadurch entstehen mehr Betriebsvarianten als notwendig.
Fehler 3: Es gibt keine Nachweise. Bei Incident, Audit, Upgrade oder Migration muss später geraten werden.

Prüffragen für Senior Entwickler

  • Welche Entscheidung wird hier wirklich getroffen?
  • Welche Alternative wurde bewusst verworfen?
  • Welche Metrik zeigt im Betrieb, ob die Annahme noch stimmt?
  • Welche Tests verhindern Rückfälle?
  • Welche Dokumentation muss im Repository liegen?
  • Welche Auswirkung hat das Thema auf Legacy-Migration, OpenShift-Betrieb und Kosten?

Merksatz

Grundregel: API Lifecycle: Versioning, Deprecation und Consumer Management ist erst Enterprise-ready, wenn Code, Contract, Betrieb, Security, Kosten und Nachweis zusammenpassen.
⌂ Cockpit