Höchster Reifegrad für REST mit HATEOAS

[ad_1]

Das Erstellen einer sauberen REST-Schnittstelle ist nicht trivial. HATEOAS ermöglicht eine klare Struktur und Aufgabenteilung.

HATEOAS ist ein in den letzten Jahren viel diskutiertes Thema: Einige bezeichnen es für REST-Schnittstellen als unverzichtbar. Andere Autoren hängen es etwas tiefer auf und bezeichnen eine HATEOAS-konforme Schnittstelle lediglich als dritten und höchsten Reifegrad von REST. Leider gibt es noch keinen einheitlichen Standard, wie HATEOAS zu implementieren ist. Ziel dieses Artikels ist es, einen Überblick über aktuelle Entwicklungen zu geben und Argumente zu liefern, warum REST-Schnittstellen auf keinen Fall darauf verzichten sollten.

Eine kleine REST-Geschichte

Die folgende Geschichte einer REST-Schnittstelle soll sich in einem Unternehmen genau so abgespielt haben. Das Ziel war die Entwicklung einer Webseite, um Wetterdaten diverser Messstationen zu präsentieren und einzulesen.

Beispiel-Screenshot für die fiktive Anwendung (Abb. 1)

Das Team beschließt, eine REST-Schnittstelle zu entwickeln, und hat die Hoffnung, sie später auch von Apps und IoT-Devices ansprechen zu können. Als vermeintlich schnellsten Ansatz programmiert es drei REST-Ressourcen, deren URL fest in den Clients verlinkt ist. Die Frage des Rechtemanagements am Client verschieben die Beteiligten auf später. Damit entsteht eine Schnittstelle, die dem Schema in Abbildung 2 entspricht.

Schematische Darstellung des simplen Service (Abb. 2)

Im nächsten Schritt wollen die Entwickler das Anlegen und Bearbeiten von Stationen durch eine Administratorrolle absichern. Um diese Information zugänglich zu machen, erstellen sie kurzerhand eine Ressource für Berechtigungen, die Abbildung 3 darstellt.

Der Service mit Administrator Berechtigung (Abb. 3)

Der Ansatz ist problematisch, da er die Bedeutung der Administrator-Rolle an zwei Stellen verankert: Am Server, wenn dort ein Request eintrifft, und am Client, der evaluieren muss, ob der derzeitige Nutzer den entsprechenden Button sehen darf. Außerdem beeinflusst der Ansatz das Laufzeitverhalten des Clients maßgeblich, der erst nach dem Laden der Berechtigungen sinnvoll eine Anzeige aufbauen kann.

Will das Team anschließend die – grundsätzlich simple – Funktion einfügen, dass jeder Nutzer seine eigenen privaten Stationen anlegen und bearbeiten darf, steht es vor weitreichenden Schwierigkeiten. Für den Fall reicht es nicht mehr aus, eine zentrale Berechtigung zu vergeben, sondern die Rechte müssen an den Objekten selbst stehen. Deswegen hängt es an jede fachliche Stationsressource die Berechtigungen des jeweiligen Nutzers.

Berechtigungsressourcen an jeder Station (Abb. 4)

Ganz verfahren wird die Situation, wenn eine Anwendung die Berechtigungsinformationen bereits beim Laden der Liste aller Stationen benötigt, wie Abbildung 5 exemplarisch zeigt. Dann bleibt dem Entwicklerteam nichts anderes übrig, als die Berechtigungen mit in die fachlichen Transferobjekte hinein zu modellieren.

Funktionen zum Löschen und Bearbeiten sollen direkt in der Listenansicht verfügbar sein (Abb. 5).

[ad_2]

Read more on: Source