30. Oktober 2020
2 Min.

Wie Consumer-Driven Contracts die Evolution von APIs ermöglichen?

In dem ersten Teil der Blogpostserie - "Evolutionäre API Entwicklung - Die Grundlage", habe ich Ihnen gezeigt wie man APIs evolutionär entwickeln kann. Im heutigen Teil zeige ich Ihnen wie das durch Consumer-Driven Contracts ermöglicht werden kann.
API Entwicklung

Was sind Consumer-Driven Contracts?

Jeder Consumer definiert explizit einen Contract, in dem nur der Teil der API definiert ist, den der Consumer verwendet. Jedes mal wenn der Provider eine neue Änderung einführt, muss er sicher stellen, dass die Consumer-Driven Contracts (von allen Consumern) weiter kompatibel bleiben. Falls nicht, gibt es Abstimmungsbedarf zwischen dem Provider und den Consumern mit fehlgeschlagenen Contracts.

Im vorherigen Blogpost habe ich Ihnen am Beispiel eines Bibliotheksbestands-Service gezeigt wie man diese API evolutionär entwickeln kann. Kurz zusammengefasst: Der Provider darf neue Felder und Endpunkte frei hinzufügen, bestehende aber nicht entfernen oder umbenennen.

Evolutionare API Entwicklung Iteration

Ich werde das selbe Beispiel zusammen mit Consumer-Driven Contracts (CDC) entwickeln. Als erstes brauche ich einen Contract für jeden der zwei Consumer. In der nächsten Iteration wird Consumer 1 mit dem Provider abstimmen, dass er zwischen ISBN-10 und ISBN-13 unterscheiden möchte. Als Folge davon ändert Consumer 1 seinen Contract und der Provider setzt die Anforderung um.

Evolutionare API mit Consumer-Driven Contract

Während der Implementierung entscheidet der Provider, das Feld isbn komplett durch isbn-13 zu ersetzen. Er weiß zu diesen Zeitpunkt noch nicht, ob andere Konsumenten von dieser Änderung betroffen sind oder nicht. Da der Provider CDC verfolgt, verifiziert er aber im nächsten Schritt alle Contracts und merkt, dass der Contract mit Consumer 2 nicht mehr einstimmt. Danach muss sich der Provider mit Consumer 2 abstimmen um eine Entscheidung zu treffen.

Durch Consumer-Driven Contracts kann man Evolutionäre APIs entwickeln und auch irgendwann Felder löschen oder umbenennen ohne Breaking Changes einzuführen.

Hier findet ihr mehr zu unserem Beratungsangebot rund um Consumer-Driven Contracts.

Warum?

Weil Contracts während der Entwicklung verifiziert sind, profitiert das Provider Team von frühzeitigen und schnellen Feedback. Der Provider kann bei potenziellen Breaking Changes erkennen welche Consumer davon betroffen sind und sie rechtzeitig informieren. Der CDC-Prozess lässt sich automatisieren, so dass das Provider und Consumer Team den größten Nutzen daraus ziehen kann. Wie das genau geht und welche Frameworks es dazu gibt erkläre ich Ihnen in meinem Blog-Beitrag Introduction to Microservices Testing and Consumer Driven Contract Testing with PACT. Weitere Vorteile von CDC erklärt Ihnen mein Kollege Axel in  Verschwendung vermeiden – Wie Consumer-Driven Contracts helfen.

Bildnachweise: © patpitchaya – stock.adobe.com

Artikel kommentieren