© StonePictures/Shutterstock.com
Wenn der Client das API spezifiziert

Kolumne: EnterpriseTales


Wie teste ich eigentlich das Zusammenspiel in meiner Microservices-Landschaft? Wie stelle ich sicher, dass jeweils die richtige Version eines Service auf der richtigen Stage deployt ist? Wie behalte ich die Abhängigkeiten meiner Microservices im Blick? Und wie stelle ich bei der Weiterentwicklung meiner APIs sicher, dass alle Clients weiterhin funktionieren? Wie kann ich sicher sein, dass eine alte Version einer Schnittstelle nicht mehr benötigt wird und deshalb entfernt werden kann? Consumer­-driven Contracts versprechen eine Lösung für alle diese Fragen, kommen aber mit einer erheblichen Komplexität und haben ihrerseits Grenzen.

Das Management der Abhängigkeiten aller Services in einer Microservices-Landschaft stellt eine der größten Herausforderungen dieses Architekturansatzes dar. Fragen danach, welcher Service welche Schnittstelle in welcher Version verwendet, müssen beantwortet werden. Weitgehende Abwärtskompatibilität der Schnittstellen ist deshalb vor allem bei public APIs Pflicht.

Bei den internen APIs, die lediglich genutzt werden, damit die Microservices untereinander kommunizieren können, kann die Sache etwas entspannter angegangen werden: Wenn ein Teil eines API von keinem Client mehr benutzt wird, kann er abgeschaltet werden, egal ob es sich dabei um einen Breaking Change handelt oder nicht. Voraussetzung dafür ist, eine Möglichkeit zu haben, die herausfindet, ob ein (internes) API noch verwendet wird oder nicht. Ein möglicher Lösungsansatz sind Consumer-driven Contracts.

Entfernen alter APIs

Normalerweise ist es so, dass der Anbieter eines API es spezifiziert und dokumentiert, um seinen Clients die Möglichkeit zu bieten, das API auf eine definierte Art zu benutzen. Im Kontext von Consumer-driven Contracts wird das als Provider Contract bezeichnet.

In der Praxis ist es allerdings häufig so, dass es keinen Client gibt, der die gesamte Breite der angebotenen Schnittstelle verwendet. Tatsächlich nutzt jeder Client in der Regel nur einen kleinen Teil einer angebotenen Schnittstelle. Dieser Teil wird als Consumer Contract bezeichnet. Die Summe der Consumer Contracts ist dann das, was der Provider tatsächlich als Schnittstelle zur Verfügung stellen muss. Häufig ist dieser Teil kleiner als der tatsächlich angebotene Provider Contract. Insbesondere, wenn der Provider noch alte Versionen von APIs anbietet, wäre ein Mechanismus wünschenswert, mit dem er feststellen könnte, dass es keinen Client mehr gibt, der diese noch benutzt.

Die Idee hinter Consumer-driven Contracts ist es, genau das zu erreichen, indem die Clients kontinuierlich ihre Consumer Contracts an den Provider übermitteln. Der kann sie dann verwenden, um seine angebotenen Schnittstellen zu testen. Alle Schnittstellen, zu denen es keinen aktuellen Consumer Contract gibt, können entfernt werden.

Aber auch wenn es darum geht, eine neue Schnittstelle zu definieren oder eine Schnittstellenerweiterung vorzunehmen, erweisen sich Consumer-driven Contracts als sinnvoll.

Anforderungspraxis

Wenn es nämlich nicht gerade um ein öffentliches API geht, ist der Normalfall, dass Schnittstellen nur geändert werden, weil einer der Clients diese Änderung benötigt. Was liegt da näher, als dass auch der Client die Änderung der Schnittstelle spezifiziert. Es versteht sich von selbst, dass das natürlich in Rücksprache mit dem Team geschehen muss, dass die Schnittstellenänderung später implementieren muss.

Mit Consumer-driven Contracts ist eine solche Möglichkeit geschaffen. Der Consumer, der die neue...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang