Höchster Reifegrad für REST mit HATEOAS
Seite 2: Aus den Designfehlern lernen
In der recht kurzen Lebenszeit der Schnittstelle haben die Entwickler somit drei große API-Breaks erzeugt. Das ist insofern problematisch, als sie gezwungen sind, die alte Version der Schnittstelle weiterhin zu unterstützen. Bei einer kontrollierten Gruppe von Clients ist der Zeitraum überschaubar, im App- und IoT-Umfeld können sie jedoch über Jahre im Einsatz sein. Das Team muss über den Lebenszyklus zusätzlich zu den fachlichen Änderungen an den eigentlichen Wetterstationen noch drei Berechtigungskonzepte pflegen. Damit ist bald der Punkt erreicht, an dem es die Entwicklung an der Schnittstelle einstellt und lieber von vorne anfängt.
Ein Blick auf die beiden Designfehler offenbart zunächst die Vermischung von Berechtigungen mit fachlichen Objekten. Weitaus schlimmer ist jedoch das Duplizieren von Client- und Servercode. Nach den Konzepten des Domain-Driven-Design [1] haben die Entwickler Teile der Server- in die Clientdomäne "sickern" lassen. Das verwässert die Grenze der beiden und führt letztlich dazu, dass eine Superdomäne entsteht, in der Server und alle Clients enthalten sind. Die einschlägige Literatur spricht von einem "verteilten Monolith" oder teilweise wenig schmeichelhaft vom "big ball of mud".
Der verstärkte Einsatz von Shared Libraries verschlechtert häufig die Situation. Sie können den gegenteiligen Effekt vom Erwünschten bringen, da das Team bei der Serverentwicklung jegliche Anforderungen der Clients berücksichtigen muss. Das widerspricht dem Anspruch, dass REST-Schnittstellen eigentlich für eine bessere Entkopplung sorgen sollen. Somit entstehen die Nachteile der verteilten Architektur, ohne einen Vorteil zu bringen.
Leider kommen die meisten REST-Schnittstellen nie über diesen Status hinaus, obwohl ein Ausweg aus dem Dilemma seit längerer Zeit bekannt ist.
Einsatz von HATEOAS
HATEOAS steht für "Hypermedia As The Engine Of Application State" und beschreibt ein Designmodell für REST-Schnittstellen. Ein Client bekommt den aktuellen Zustand der Applikation von den Ressourcen einer REST-Schnittstelle mitgeteilt. Darüber hinaus übermittelt der Server alle möglichen Zustandsübergänge in Form von Hypermedia-Links. Die Domäne des Servers schließt sich somit, da der Client kein Wissen über die Berechnung der Statusübergänge benötigt. Der Client muss "nur noch" die Linknamen, die sogenannten Relationen und eine dedizierte Einsprung-URL kennen, von der er starten kann.
Die Konstellation bringt übrigens die Versuchung mit sich, die Links zum Dokumentieren zu (miss-)brauchen. Jedoch ist es eine Illusion, dass Entwickler lediglich vor der Schnittstelle sitzen müssen, um ihre Funktionsweise zu erkennen. Das kann HATEOAS nicht leisten. Durch den grundsätzlich dynamischen Ansatz sind selten alle möglichen Links auf Anhieb sichtbar. Eine geeignete Dokumentation ist somit weiterhin erforderlich.
Relationen im Zentrum
Die zentrale Rolle bei HATEOAS nehmen die Relationen ein. Entwickler müssen einen geeigneten Weg finden, die Semantik zum Client zu transportieren. Ansatzweise beschreibt RFC5988 das Vorgehen. Für Standardrelationen existiert eine Registry bei der IANA (http://www.iana.org/assignments/link-relations/link-relations.xhtml). Die RFC bleibt jedoch (bewusst?) vage hinsichtlich des Einfügens eigener Relationen. Roy Fielding schlägt dazu zwei Vorgehensweisen vor. Die erste ist die Verwendung eines eigenen Medientyps.
Dabei müssen Entwickler jedoch aufpassen, dass sie nicht für jedes Businessobjekt und für jede Version einen eigenen Typ einführen. Ansonsten entsteht erneut eine Art Shared Library und damit eine enge Kopplung. Außerdem explodiert damit die Anzahl der zu verwaltenden Medientypen. Dass das erfahrungsgemäß in einem (eher ungeeigneten, weil nicht maschinenlesbaren) Wiki-System erfolgt, verschlimmert die Situation nur weiter.
Das andere Extrem wäre, einen sehr generischen Medientyp ohne jegliche eigene Relationen zu wählen. Das birgt die Gefahr, dass am Ende ein Äquivalent zu HTML entsteht. Die Wartung und Entwicklung eines solchen Typs und des zugehörigen Clients ist äußerst aufwendig. Es gilt also, einen gesunden Mittelweg zu finden.
