REST und HATEOAS

Von Kai Tödter, Axel Morgner, Christian Morgner und 2 weiteren

Dieser shortcut richtet den Blick auf Hypermedia as the Engine of Application State, kurz HATEOAS. Anhand konkreter Beispiele wird gezeigt, warum RESTful Hypermedia-APIs sinnvoll und nützlich sind. Anschließend wird die quelloffene Software Structr genauer unter die Lupe genommen. Sie erleichtert aufgrund ihres JSON-/REST-Servers das Erstellen mobiler Webanwendungen enorm. Zu guter Letzt widmen sich die Autoren zwei Aspekten aus den Praxisbereichen Design und Technik: Sie zeigen, wie mithilfe von HATEOAS bessere REST-APIs entworfen werden können und werfen einen Blick auf Spring HATEOAS. Zum Verständnis dieses shortcuts wird ein grundsätzliches Verständnis von REST und Spring vorausgesetzt.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 30. Juli 2015
• ISBN: 9783868025552

Buchvorschau

GmbH

1 HATEOAS - ein Überblick

RESTful Web Services sind schon seit einiger Zeit in aller Munde und sehr beliebt. Viele der bekannten öffentlichen Web-APIs behaupten von sich, RESTful zu sein. Die meisten sind es allerdings nicht wirklich, unter anderem, da sie ein wichtiges Element von REST nicht erfüllen: Hypermedia as the engine of application state (HATEOAS). Dieses Kapitel gibt einen Überblick über das Thema und zeigt an vielen konkreten Beispielen, warum RESTful Hypermedia APIs sinnvoll und sehr nützlich sind.

Ich beschäftige mich schon seit einiger Zeit ausgiebig mit RESTful Web Services und habe einige Erfahrung mit Client- und Serverentwicklung gesammelt. Dabei bin ich immer wieder auf Diskussionen gestoßen, die sich mit dem Thema beschäftigen, was die Best Practices in diesem Bereich sind. Viele der vermeintlichen REST-APIs, die man im Internet findet, sind eigentlich gar nicht RESTful (im Sinne von Roy Fieldings Dissertation). Wenngleich immer mehr APIs einige der Architekturprinzipien erfüllen, gibt es einen Bereich, der noch sehr wenig Verbreitung in heutigen APIs hat: Hypermedia as the engine of application state, auch oft abgekürzt mit dem unaussprechlichen Akronym HATEOAS. Einige Leute sprechen es übrigens wie „hate-ee-os (so ähnlich wie „hideous) oder wie „hate O-A-S" aus.

Aus Platzgründen möchte ich auf die von REST geforderten Architekturprinzipien nicht im Detail eingehen. Eine gute Erläuterung dieser Prinzipien finden Sie unter [1] und [2]. Dieses Kapitel widmet sich hauptsächlich dem Punkt HATEOAS. Dabei liefern die Repräsentationen einer Ressource nicht nur eigene Attribute sondern auch mögliche Zustandsänderungen (z. B. in Form von Links) und andere Informationen, mit dem Ziel, die APIs robuster und selbstbeschreibender zu machen.

Motivation

Stellen Sie sich kurz vor, Sie öffnen Ihre Lieblingswebseite im Browser. Sie sehen dort sofort, ob es einen für Sie interessanten Link gibt. Wenn Sie auf den Link klicken, öffnet Ihr Browser eine weitere Webseite, die den für Sie interessanten Inhalt liefert. Wichtig hierbei ist, dass es für Sie in erster Linie uninteressant ist, wo genau der Link hingeführt hat (also der URI des Links). Wenn morgen der Inhalt auf einen anderen Server oder andere Domain umziehen würde, würden Sie das erstmal gar nicht merken, da Ihre Lieblingswebseite den URI des Links aktualisiert hätte, dieser aber für Sie als Benutzer hinter einem markierten Text versteckt ist. Das genau ist eine der Ideen von RESTful Hypermedia APIs: Die Repräsentationen von REST-Ressourcen liefern also noch weiterführende Informationen mit, z. B. wo es weitergeht und was man noch Sinnvolles tun kann.

Media-Type und Repräsentationen

Es gibt keinen Standard für die Repräsentation von Hypermedia, allerdings gibt es eine ganze Reihe von Vorschlägen und Spezifikationen, auf die ich hier etwas ausführlicher eingehen möchte. Aus Platzgründen beschränke ich mich auf folgende drei:

HAL (Hypertext Application Language)

Siren

Collection+JSON

HAL

Science-Fiction-Fans denken oft