Unternehmens-APIs mit Microservices
Der immer beliebter werdende Microservices-Ansatz kann eine hohe Anzahl an APIs produzieren: Es gibt verschiedene Optionen, diese über Unternehmensgrenzen hinweg zu präsentieren.
- Jörg Adler
Das Microservice-Architektur-Pattern erfreut sich großer Beliebtheit. Da weniger Businesscode durch einen Service behandelt wird, steigt dabei zwangsläufig die Anzahl der Services. Jeder dieser kleinen Services hat wiederum eine API. Dadurch produziert man eine hohe Anzahl dieser Programmierschnittstellen.
Zusätzlich rückt das Erstellen von REST-APIs in den Fokus von Unternehmen. Solche APIs sollen allumfassend sein und wie aus einem Guss wirken. Das heißt, es soll einheitliche Formate, Verlinkungen und Dokumentationen geben. Man will es dem Kunden nicht zumuten, sich in viele kleine Microservice-APIs einzudenken, von denen alle unterschiedliche Auffassungen von fachlichen Entitäten haben. Vor allem wenn man als Grenze eines Services einen Bounded Context aus dem Domain-driven Design wählt, ist diese Dopplung von Begriffen mit jeweils unterschiedlichen Bedeutungen in verschiedenen Kontexten (und damit Services) nicht zu vermeiden.
Diese Diskrepanz von fachlichen und technischen Anforderungen gilt es zu lösen. Der Einfachheit halber beschränkt sich der Artikel vornehmlich auf REST-Services mit HATEOAS.
Zur Illustration hilft zunächst ein kleines Beispiel. Service A ist ein Service für das Ausliefern von Artikelinhalten. Service B ist ein Service für Artikelbewertungen.
Die REST-Schnittstelle von Service A liefert unter der URL A/articles/{id} eine reichhaltige Beschreibung eines Artikels inklusive Bildern, Preis und weiteren Informationen. Bei Service B findet man unter der URL B/articles/{id} nur die id, eine Gesamtbewertung ("Sterne") und mehrere Links. Zum Beispiel den Link "ratings", der auf B/articles/{id}/ratings zeigt. Dazu kommen unter anderem noch Links zum Anlegen neuer Bewertungen.
In den APIs beider Services existieren Root-Ressourcen, die jeweils einen Link "article" enthalten, der auf .../articles/{id} zeigt. Die Existenz der Artikel leitet Service B aus einem zentralen Eventstream ab. Aus diesem bezieht Service A ebenfalls seine Daten.
Mit diesem Setup haben Entwickler erst einmal nichts falsch gemacht. Jeder Microservice korrespondiert schön mit einem Bounded Context. Die jeweiligen APIs sind in sich geschlossen. Um allerdings aus den APIs der beiden Services eine API nach außen zu bilden, hat man unterschiedliche Optionen.
