Ich habe eine Reihe von Versionierungsschemas für REST API (Header, URL, ...) ausgewertet. Der bisher zuverlässigste Ansatz scheint die URL-Option zu sein: Sie funktioniert mit Proxies und verlässt sich nicht auf obskure Schemata wie Daten für die Versionierung .
Wenn ich mich jetzt umsehe, scheint jeder, der den URL-basierten Ansatz verwendet, Versionen wie v1 , v2 usw. zu verwenden. Niemand verwendet Nebenversionen oder gar ein Schema wie semantische Versionierung .
Dies wirft einige Fragen auf:
Mit anderen Worten: Wie kann ein Unternehmen wie GitHub beispielsweise heute nur noch v3 (2015) haben, wenn es bereits seit 7 Jahren im Geschäft ist? Bedeutet das, dass sie ihre api nur zweimal geändert haben? Das kann ich kaum glauben.
Irgendwelche Hinweise?
Die Hauptversionsnummer ist alles, was Sie für einen Webdienst benötigen. Weil Ihre Kunden sich nur für rückwärtskompatible Änderungen interessieren und (wenn Sie die semantische Versionierung korrekt befolgen) werden diese nur dann eingeführt, wenn eine neue Hauptversion veröffentlicht wird.
Alle anderen Änderungen (einschließlich neuer Funktionen, Bugfixes, Patches usw.) sollten für Ihre Kunden "sicher" sein. Diese neuen Funktionen müssen nicht von Ihren Kunden verwendet werden, und wahrscheinlich möchten Sie die nicht gepatchte Version, die den Bug X oder Y enthält, wahrscheinlich nicht länger als nötig ausführen.
Wenn Sie die vollständige Versionsnummer in Ihren URLs (oder einer anderen für die API-Versionierung verwendeten Methode) verwenden, müssen Ihre Konsumenten die URL Ihrer API jedes Mal aktualisieren, wenn Sie ein Update / Bugfix für Ihre API erstellen Verwenden Sie eine nicht gepatchte Version, bis sie dies tun.
Das bedeutet nicht, dass Sie die semantische Versionierung natürlich nicht intern verwenden können! Verwenden Sie einfach den ersten Teil (Hauptversion) als Versionsnummer für Ihre API. Es macht einfach keinen Sinn, die vollständige Versionsnummer in Ihr URL / Header / anderes Versionsverwaltungssystem aufzunehmen.
Um Ihre Frage zu beantworten: Sie aktualisieren Ihre API jedes Mal, wenn Sie eine neue Version erstellen, aber Sie geben nur eine neue API-Version frei, wenn Sie eine neue Hauptversion haben. Auf diese Weise müssen Sie nur ein paar verschiedene Versionen hosten (und Sie können natürlich alte Versionen im Laufe der Zeit ablehnen).
Tags und Links api rest versioning semantic-versioning