Wie unterstützen Consumer-Driven Contracts API-First Design?

Wenn ich einen Service implementiere und weiß, dass ich eine API für eine bestimmte Funktionalität anbieten möchte, habe ich mehrere Möglichkeit, meine Arbeit anzugehen.

Schnittstellen-Implementierung ohne API-First Design

Ich kann erst einmal den Code fertigstellen und danach die API implementieren. Der API-Design-Schritt wird oft nicht explizit gemacht und stattdessen direkt in die technische Implementierung integriert. Auf der anderen Seite stehen die Consumer der Schnittstelle, die auf das Provider-Team warten müssen, bis es bereit ist ihnen die API zur Verfügung zu stellen. Der Nachteil dieses Vorgehens liegt also im Blockieren der Consumer-Teams. Ein weiterer Nachteil ist auch, dass Feedback der Consumer zu der API zu spät ankommt und mögliche Missverständnisse zwischen Consumern und Provider zu spät erkannt werden.

API-First Design

Wenn ich bei der Umsetzung stattdessen den API-First Design Ansatz verfolge, dann werde ich mir zunächst Gedanken über die API machen, wie sie aussehen wird, und welche Informationen mir noch eventuell fehlen. Die Consumer können in diese Überlegungen frühzeitig eingebunden werden, so dass sie mit konkreten Wünschen die API mitgestalten können. Anschließend, wenn der Entwurf der API zwischen Consumer und Provider geklärt ist, kann jede Seite für sich parallel mit der Umsetzung starten.

Sind Consumer-Driven Contracts (CDCs) = API-First Design?

CDCs sind mit API-First Design absolut kompatibel. Die Frage ist, ob die API aus Sicht der Consumer oder der Provider entworfen ist.

Wenn ich eine öffentlich verfügbare API anbiete, dann bin ich eher Provider-Driven. Die Konsumenten meiner API sind mir nicht alle bekannt, und ich kann nicht jeden einzelnen Wunsch berücksichtigen. Das bedeutet, ich definiere aus meiner Perspektive als Provider, wie die API aussehen soll. Die Möglichkeit API-First Design umzusetzen bleibt dennoch bestehen.

Wenn ich stattdessen innerhalb einer Organisation viele verteilte Services habe und ich den API-First Ansatz verfolgen will, dann habe ich die Wahl, das mittels Consumer-Driven Contracts umzusetzen. Die Motivation dafür, Consumer-Driven statt Provider-Driven APIs zu entwerfen, erklärt Ihnen mein Kollege Axel. Der Unterschied ist, dass die Consumer zuerst ihre Erwartungen an die API festhalten, und diese Definition formal in Form eines Contracts dem Provider zur Verfügung stellen. So bin ich als Provider früh über die Bedürfnisse meiner Consumer informiert, was mir dabei hilft viele unnötige Abstimmungsaufwände und ungenutzte Funktionalität zu vermeiden.

Consumer-Driven Contracts sind also kompatibel mit API-First Design, bieten aber gleichzeitig weitere Vorteile. Der Consumer implementiert seine Geschäftslogik nicht nur gegen seine Annahmen über das Verhalten des Providers, er lässt diese Annahmen dem Provider als Contract zukommen. So kann der Provider stets verifizieren, dass er die Erwartungen aller Consumer erfüllt, und auch mit wem er für etwaige API-Änderungen das Gespräch suchen muss.

Mehr zu unserem Beratungsangebot rund um Consumer-Driven Contracts finden Sie hier.