Interview mit Oliver Drotbohm

API-Design: „Wenn hier der Blick für’s Ganze fehlt, verstrickt man sich schnell“

Thomas Petzinna

Was ist der Unterschied zwischen API und REST APIs? Was muss bei der API-Entwicklung beachtet werden und wieso sollte man REST auf keinen Fall vernachlässigen? Oliver Drotbohm, Leiter des Spring-Data-Projekts bei Pivotal, beantwortet diese Fragen ausführlich im Interview von der API Conference 2019 in Berlin.

Viele APIs werden heutzutage REST APIs genannt, tauschen allerdings hauptsächlich Daten via HTTP und JSON aus. Gleichzeitig agieren immer mehr Systeme nicht mehr isoliert, sondern interagieren mit anderen. In diesem Kontext ist es besonders wichtig, APIs gut weiterentwickeln und ändern zu können und die hemdsärmelige Antwort darauf lautet üblicherweise: Versionierung.

Oliver Drotbohm macht in seinem APICon-Vortrag „APICon-Session „REST beyond the Obvious – API Design for ever-evolving Systems“ einen Schritt zurück und schaut als erstes auf den architektonischen Kontext, in dem APIs leben, und skizziert die Nachteile eines Designs, der Kernbestandteile von REST vernachlässigt. Er bespricht interne und externe APIs, inwieweit diese Unterscheidung überhaupt Sinn ergibt, den Einfluss von Domain-driven Design und wie man APIs so spezifiziert, dass sie für Erweiterbarkeit optimiert sind, sodass Änderungen existierende Clients möglichst nicht brechen. Wir haben Oliver Drotbohm einige Fragen rund um seine Session gestellt.

JAXenter: In Deiner APICon-Session legst Du beim Thema Versionierung den Finger in der Wunde. Wo siehts Du bei diesem Punkt gravierende Schwächen?

Oliver Drotbohm: Es ist der zweite Schritt vor dem ersten. Viele Teams beschließen eine Versionierungsstrategie, noch bevor sie darüber nachgedacht haben, welche Mittel und Wege es gibt, ein API zu gestalten, dass die Notwendigkeit für eine neue Version möglichst selten ist. Diese Möglichkeiten werden selten ausgenutzt bzw. oft einfach schlicht überhaupt nicht in Erwägung gezogen.

Es gibt zum Teil recht auffällige Symbiosen zwischen Domain-Driven Design und der Art und Weise, wie REST funktioniert.

Der zweite Punkt dazu ist, dass es ein „Aufwandsungleichgewicht“ zwischen API Konsument und Anbieter gibt, um auf eine neue Version zu migrieren. Eine neue Version ist oft eine sehr lokale, ökonomische Entscheidung des anbietenden Teams, weil es die Aufwände scheut, die es benötigt, um ein API kompatibel weiterzuentwickeln. Betrachtet man allerdings den Gesamtaufwand der Migration zu einer neuen Version, übersteigt der gerade bei eine größeren Anzahl an Clientsystemen diese Ersparnis enorm. Dies ist vor allem in Microservicesystemen ein Problem, da hier per Definition Entscheidungen in einem Serviceteam getroffen werden. Wenn hier der Blick für’s Ganze fehlt, verstrickt man sich schnell.

Es gibt eine recht wissenschaftliche Analyse von Jacques Dubray zu diesem Thema, die sehr schön deutlich macht, wie sich diese Art Kosten in Bezug auf verschiedene Weiterentwicklungsstrategien verhält.

JAXenter: Bei der API-Entwicklung spielt der architektonische Kontext von Client-Servers-Architekturen eine große Rolle. Welche Nachteile hat aus Deiner Sicht ein Design, das Kernbestandteile von REST vernachlässigt?

Oliver Drotbohm: Architekturstile sind eigentlich eine Abbildung von Beschränkungen im Lösungsraum (welche Dinge sollte ich tun, welche nicht?) hin zu den zu erwartenden Eigenschaften eines Systems. REST z. B. erreicht Skalierbarkeit des Gesamtsystems unter anderem durch die Anforderung der Zustandslosigkeit der Kommunikation. Wenn ich diese jetzt in meinem Systementwurf ignoriere, ist es sehr unwahrscheinlich, Skalierbarkeit zu erreichen.

Eine beliebte initiale Reaktion auf solcherlei Phänomene ist es, das API als „nicht-REST“ zu beschreiben. Jedoch dreht sich die Diskussion eigentlich nicht um „Ist das REST oder ist es das nicht?“, sondern darum, welche Ziele ich mit meiner Architektur erreichen will und ob mir vielleicht das Ignorieren bestimmter Anforderungen das Erreichen dieser Ziele sehr schwer macht.

JAXenter: Welchen Stellenwert haben für Dich Hypermedia und Hypertext im Kontext von REST?

Oliver Drotbohm: Der Hypermedia-Constraint in REST, der gern mit „Brauchen wir nicht!“ hinten angestellt oder sogar explizit ignoriert wird, ist fundamentale Voraussetzung dafür, die Kopplung zwischen Client und Server so gering wie möglich zu halten. Er ermöglicht es, fachliche Entscheidungen, wie z. B. ob eine Bestellung in genau diesem Zustand stornierbar ist oder nicht, zu einem einfachen „Ist der Link xyz in der Representation enthalten?“ zu reduzieren.

Dazu muss ich dem Client zwar etwas mehr Protokollwissen mitgeben, da er plötzlich wissen muss, wie Links in der Representation aussehen, wie URL Templates funktionieren usw. Ich sorge aber gleichzeitig dafür, dass der Client wesentlich weniger Domänenwissen in sich tragen muss. Domänenwissen, dass ich ja per Definition zwischen Client und Server replizieren würde. Je weniger ich also von diesem im Client trage, desto leichter wird es, diese Logik zu verändern. Und diese leichte Möglichkeit Fachlichkeit reibungslos zu ändern und schnell produktiv du deployen, steht eigentlich im Mittelpunkt moderner Architekturansätze wie Microservices.

Der Hypermedia-Constraint in REST, der gern mit „Brauchen wir nicht!“ hinten angestellt oder sogar explizit ignoriert wird, ist fundamentale Voraussetzung.

JAXenter: Du beschäftigst Dich auch mit der Abbildung von Geschäftsprozessen in die Client-Server-Architektur. Was muss ich bei der Integration und Modellierung von verteilten Geschäftsprozessen besonders beachten?

Oliver Drotbohm: Es gibt zum Teil recht auffällige Symbiosen zwischen Domain-Driven Design und der Art und Weise, wie REST funktioniert. Fachliche Ereignisse schlagen sich üblicherweise in Zustandsübergängen auf Aggregaten nieder. Zustandsübergänge einer Ressource sind auch zentraler Bestandteil von REST. Ein guter Ausgangspunkt kann es also sein, sich beim Design der Ressourcen an den Aggregatgrenzen zu orientieren und dann eben, die möglichen Zustandsübergänge durch Hypermediaelemente anzupreisen und den Client entsprechend so zu implementieren, dass er diese nutzt.

Wichtig ist hierbei aber das Wort Inspiration. Zu oft wird dieser Ansatz missverstanden und das API degeneriert zu einem Datenbank API auf HTTP Ebene mit dem jede Entität – eigentlich jede Datenbanktabelle – per Request modifiziert werden kann. Dies sorgt dafür, dass eben die oben genannten Effekte der Abstraktion über die eigentliche Fachlichkeit verloren geht. Es ist also essentiell, zumindest in Aggregaten zu denken, noch besser in Events die einen Prozess treiben.

JAXenter: Ein weiteres spannendes Thema ist das Konzept der „Connascence“, das den Begriff der Kopplung pragmatisch erweitert. Wie siehst Du dieses Thema?

API Confernce 2020
Milecia McGregor

The 3 Axes of Scaling APIs

Milecia McGregor (Flipped Coding)

 

Oliver Drotbohm: Connascence ist der Grad der Kopplung zwischen zwei zusammen „geborenen“ Konzepten, die miteinander interagieren: eine Klasse auf der einen Seite und Code, der diese verwendet auf der anderen. Je nach Programmiersprache herrscht hier eine recht starke Kopplung, da z. B. die Aufrufreihenfolge der Parameter stimmen muss usw. Diese hohe Kopplung ist gewünscht, da sie uns ermöglicht, den Code zu refaktorisieren und der Compiler uns mitteilen kann, wenn Dinge nicht zueinander passen.

Was jedoch irritierend ist, ist dass oft versucht wird, die gleiche Art der Schnittstellenbeschreibung auf Web APIs zu übertragen, obwohl man bei denen eigentlich qua Definition starke Kopplung vermeiden möchte. Man scheint also zu Versuchen, mit dem gleichen Mittel etwas fundamental anderes zu erreichen. Oft schlägt das fehl und die Erfahrung wird zu „REST funktioniert nicht“ destilliert.

Meiner Meinung nach Bedarf es hier einer fundamental anderen, vergebenderen, minimalistischeren Herangehensweise, das bewusste Vermeiden der Dokumentation von Details auf der Serverseite und das akribische minimalisieren des Clients darauf, wirklich nur die Dinge eines Responses zu referenzieren, die zwingend benötigt werden und das auch nur in einer Tiefe, die unbedingt notwendig ist. Hypermediaelemente im API sind hier ein Schlüsselbaustein.

JAXenter: Vielen Dank für das Interview!

Oliver Drotbohm ist Leiter des Spring-Data-Projekts bei Pivotal. Seit über zwölf Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mitglied der JPA Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Domain-driven Design, REST, Spring und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln und des ersten Spring-Data-Buchs.
Geschrieben von
Thomas Petzinna
Thomas Petzinna
Thomas Petzinna studierte Wirtschaftskommunikation an der FHTW Berlin. Als Spezialist für strategisches Content Marketing, SEO und Social Media liegt sein Fokus darüber hinaus auf das Thema Digitalisierung. Bei Software & Support Media ist er als Redakteur für entwickler.de und das PHP Magazin zuständig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: