Freigeben über

Erstellen, Entwickeln und Versionsverwaltung von Microservice-APIs und Verträgen

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

.NET Microservices-Architektur für containerisierte .NET-Anwendungen eBook-Cover-Thumbnail.

Eine Microservice-API ist ein Vertrag zwischen dem Dienst und seinen Clients. Sie können einen Microservice unabhängig entwickeln, wenn Sie den API-Vertrag nicht unterbrechen, weshalb der Vertrag so wichtig ist. Wenn Sie den Vertrag ändern, wirkt sich dies auf Ihre Clientanwendungen oder Ihr API-Gateway aus.

Die Art der API-Definition hängt davon ab, welches Protokoll Sie verwenden. Wenn Sie beispielsweise Messaging wie AMQP verwenden, besteht die API aus den Nachrichtentypen. Wenn Sie HTTP- und RESTful-Dienste verwenden, besteht die API aus den URLs und den Anforderungs- und Antwort-JSON-Formaten.

Selbst wenn Sie jedoch über Ihren ursprünglichen Vertrag nachgedacht haben, muss sich eine Dienst-API im Laufe der Zeit ändern. In diesem Fall – und insbesondere, wenn Ihre API eine öffentliche API ist, die von mehreren Clientanwendungen genutzt wird – können Sie in der Regel nicht erzwingen, dass alle Clients auf Ihren neuen API-Vertrag aktualisiert werden. In der Regel müssen Sie neue Versionen eines Diensts inkrementell so bereitstellen, dass sowohl alte als auch neue Versionen eines Dienstvertrags gleichzeitig ausgeführt werden. Daher ist es wichtig, eine Strategie für Ihre Dienstversionsverwaltung zu haben.

Wenn die API-Änderungen klein sind, z. B. wenn Sie Ihrer API Attribute oder Parameter hinzufügen, sollten Clients, die eine ältere API verwenden, wechseln und mit der neuen Version des Diensts arbeiten. Möglicherweise können Sie Standardwerte für fehlende Attribute bereitstellen, die erforderlich sind, und die Clients können möglicherweise zusätzliche Antwortattribute ignorieren.

Manchmal müssen Sie jedoch wichtige und inkompatible Änderungen an einer Dienst-API vornehmen. Da Sie möglicherweise nicht erzwingen können, dass Clientanwendungen oder -dienste sofort auf die neue Version aktualisiert werden, muss ein Dienst ältere Versionen der API für einen bestimmten Zeitraum unterstützen. Wenn Sie einen HTTP-basierten Mechanismus wie REST verwenden, besteht ein Ansatz darin, die API-Versionsnummer in die URL oder in einen HTTP-Header einzubetten. Anschließend können Sie zwischen der gleichzeitigen Implementierung beider Versionen des Diensts innerhalb derselben Dienstinstanz oder der Bereitstellung verschiedener Instanzen entscheiden, die jeweils eine Version der API verarbeiten. Ein guter Ansatz für diese Funktionalität ist das Mediator-Muster (z. B. MediatR-Bibliothek), um die verschiedenen Implementierungsversionen in unabhängige Handler zu entkoppeln.

Wenn Sie schließlich eine REST-Architektur verwenden, ist Hypermedia die beste Lösung für die Versionsverwaltung Ihrer Dienste und das Zulassen von volvierbaren APIs.

Weitere Ressourcen

ZurückWeiter