Da Services unabhängig bereitgestellt werden, kannst du niemals annehmen, dass Aufrufer synchron aktualisieren. API-Versionierung plus Abwärtskompatibilität ermöglicht es Producern, sich weiterzuentwickeln, ohne bestehende Consumer zu beschädigen.
Da Services unabhängig bereitgestellt werden, kannst du niemals annehmen, dass Aufrufer synchron aktualisieren. API-Versionierung plus Abwärtskompatibilität ermöglicht es Producern, sich weiterzuentwickeln, ohne bestehende Consumer zu beschädigen.
| Strategie | Beispiel |
|---|
| URI-Pfad | GET /v2/orders/42 |
| Header | Accept: application/vnd.api.v2+json |
| Schema-Evolution | Felder hinzufügen, niemals entfernen/umbenennen |
NON-BREAKING (safe):
✓ add a new optional field
✓ add a new endpoint
✓ add a new enum value (if clients tolerate unknowns)
BREAKING (needs a new version):
✗ remove or rename a field
✗ change a type or make a field required
✗ change semantics of an existing field
message Order {
string id = 1;
double total = 2;
string currency = 3; // NEW field 3 — old clients ignore it safely
}
Feldnummern, nicht Namen, definieren das Wire-Format, daher ist das Hinzufügen von Feldern abwärtskompatibel.
Release v2 ─▶ run v1 + v2 together ─▶ migrate consumers ─▶ deprecate v1 ─▶ remove v1
Entferne nie eine Version, während echter Traffic sie noch verwendet. Verfolge die Nutzung vor dem Stilllegen.
Unabhängige Bereitstellbarkeit funktioniert nur, wenn ein Producer eine Änderung versenden kann, ohne das Release jedes Consumers zu koordinieren.
Das Entwerfen für additive Änderungen und das Unterstützen alter Versionen während der Migration ist das, was diese Unabhängigkeit bewahrt, anstatt fragile Big-Bang-Upgrades zu erzwingen.