Representational State Transfer – besser bekannt unter seiner Kurzform REST – zählt zu den wichtigsten Programmierparadigmen moderner Webentwicklung. Der Architekturstil, den Roy Fielding im Jahr 2000 in seiner Dissertation präsentierte, dient in erster Linie dem Ziel, Web-Applikationen optimal an die Anforderungen des modernen Webs anzupassen. Weil REST in der jüngeren Vergangenheit spürbar an Popularität und Bedeutsamkeit gewonnenhat, bemühen sich viele Webprojekt-Betreiber zunehmend, das Konzept nach bestem Gewissen umzusetzen. Die Ergebnisse dieser Bemühungen sind oftmals allerdings nicht wirklich „RESTful“ bzw. „REST-konform“, da bestimmte Prinzipien und Eigenschaften (wie HATEOAS) nicht in angemessener Form umgesetzt wurden.
HATEOAS ist ein Akronym, das für „Hypermedia as the Engine of Application State“ (dt. Hypermedia als Motor des Anwendungszustands) steht. Dieser Begriff, den Fielding im Rahmen seiner REST-Definition eingeführt hat, beschreibt eine der entscheidenden REST-Eigenschaften: Da der Architekturstil eine universelle Schnittstelle bieten soll, fordert HATEOAS nämlich, dass der REST-Client sich ausschließlich durch das Folgen von URIs (Uniform Resource Identifier) im Hypermedia-Format durch die Webanwendung bewegen kann. Wird dieses Prinzip umgesetzt, benötigt der Client abgesehen von einem grundsätzlichen Verständnis von Hypermedia keinerlei weitere Informationen, um mit der Applikation bzw. dem Server interagieren zu können.
Die Bereitstellung der einzelnen URIs erfolgt dabei beispielsweise:
Durch die Umsetzung des HATEOAS-Prinzips lässt sich dieSchnittstelle eines REST-Services jederzeit anpassen, was ein wichtiger Vorteil dieser Architektur gegenüber anderen Applikationsstrukturen ist – beispielsweise gegenüber solchen, die auf Grundlage von SOAP (Simple Object Access Protocol) funktionieren.
Um HATEOAS und seine Bedeutung für REST-Anwendungen einordnen zu können, muss man einen Blick auf das Gesamtkonstrukt werfen. Fielding beschreibt in seinem Konzept insgesamt fünf Grundprinzipien, die es zu erfüllen gilt, um einen Service REST-konform zu gestalten.
Mit dem weiteren Klick laden Sie das Video von YouTube. In diesem Fall kann YouTube Cookies setzen, auf welche wir keinen Einfluss haben.
So muss in jedem Fall eine Client-Server-Struktur vorliegen, die darüber hinaus eine zustandslose Kommunikation zwischen Server und Clients ermöglicht (Anfragen werden also ohne Bezug zu vorherigen Anfragen behandelt). Des Weiteren sollte der Dienst mehrschichtig aufgebaut sein und die Vorteile von HTTP-Caching nutzen, um die Nutzung des Services für den zugreifenden Client so einfach wie möglich zu gestalten. Schließlich gehört auch die bereits erwähnte Realisierung einereinheitlichen Schnittstelle zu den Pflichtaufgaben.
Für die Verbindung zwischen Server und Client schreibt Fielding folgende vier Eigenschaften vor:
HATEOAS ist also eine der elementaren Eigenschaften von REST-APIs und als solche für jeden REST-Service unverzichtbar.
Nähere Informationen zu REST finden Sie in unserem Grundlagenartikel zum Thema.
Um das HATEOAS-Konzept etwas greifbarer zu machen, soll die Umsetzung im folgenden Abschnitt am Beispiel eines Webshops verdeutlicht werden. HATEOAS wird hierbei, wie für Webanwendungen typisch, über das Setzen von Hyperlinks realisiert. Diese Querverweise zwischen zwei Dokumenten bzw. Querverweise zu einer anderen Stelle im selben Dokument werden in HTML unter anderem folgendermaßen gekennzeichnet:
<a href="URI">Link-Text</a>Auf diese Weise verknüpfte Medien – wie zum Beispiel Text, Grafik, Audio und Video – bezeichnet man als Hypermedia. Bei Webanwendungen handelt es sich dabei vor allem um einfache Textdokumente im HTML -Format, die man auch als „Zustände“ (englisch „states“) dieser Anwendungen ansehen kann. Im Rahmen der REST-Philosophie sind die einzelnen Dokumente immer über einen einzigartigen URI adressierbar. Überträgt man das Konzept auf einen gewöhnlichen Onlineshop, ergibt sich daraus Folgendes:
Das Dokument, das den Zustand „Warenkorb“ beschreibt, hat einen fest zugewiesenen URI – zum Beispiel 'example.org/warenkorb'. Im gleichen Stil gibt es auch URIs für die einzelnen Artikel, die in den Warenkorb gelegt werden können – wie beispielsweise 'example.org/artikel/1', 'example.org/artikel/2'usw.Ein weiterer möglicher Zustand ist das Kundenkonto, das sich direkt aus dem Warenkorb heraus aufrufen lässt und folgenden URI haben könnte: 'example.org/kunde/1'. Jedes einzelne Dokument enthält darüber hinaus Verweise bzw. Hyperlinks auf Aktionen, die der Anwender als nächstes ausführen könnte.
Um beim vorliegenden Szenario zu bleiben, bedeutet das für das Warenkorb-Dokument also, dass dieses auch Querverweise zu den Artikel- und Kunden-URIs enthält. Diese könnten ihrerseits weitere Verweise zu Herstellern oder Vertragsunterlagen beinhalten. Per GET-Request bewegt sich der Client dann dank der verschiedenen Hyperlink-Verknüpfungen durch den Shop bzw. in diesem Fall durch den Warenkorb, wie die folgende, vereinfachte Grafik verdeutlicht.
Bei einem REST-Service, in dem der HATEOAS-Grundsatz wie von Fielding gefordert befolgt wurde, muss der User also lediglich den Start-URI kennen, um das Angebot wie vom Entwickler geplant wahrnehmen zu können.
Anhand der zuvor aufgezeigten Webshop-Struktur lässt sich auch die mögliche Kommunikation zwischen Client und Server erläutern. So stellt die Client-Anwendung folgenden Request, um eine XML-Repräsentation des Warenkorb-Zustands zu erhalten:
GET https://example.org/warenkorb HTTP/1.1
Host: https://example.org
Accept: application/xmlDie Antwort des Servers könnte dann folgendermaßen aussehen:
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 256
<?xml version="1.0"?>
<warenkorb>
<warenkorb_number>1</warenkorb_number>
<link rel="konto" href="https://example.org/kunde/1" />
<link rel="artikel1" href="https://example.org/artikel/1" />
<link rel="artikel2" href="https://example.org/artikel/2" />
</warenkorb>
Die Zusammenarbeit verschiedener Anwendungssysteme ist im Laufe der vergangenen Jahre immer wichtiger geworden – insbesondere aufgrund der ständig steigenden Zahl mobiler Geräte. Um auf diesen Trend zu reagieren, wurden zahlreiche Webservices entwickelt, die den systemübergreifenden Datentransfer ermöglichen. Der Representational State Transfer (REST), ein Paradigma, das bereits im Jahr 2000...
NoSQL-Datenbanken sind längst zu ernsthaften Alternativen der klassischen relationalen Datenbanksysteme wie MySQL geworden. Sie ersetzen die fest definierte Speicherstruktur der traditionellen Modelle durch flexible Sicherungsverfahren. Auf diese Weise kann z. B. der Datenbestand unkompliziert auf mehrere Server verteilt werden, um eine hohe Verfügbarkeit von Webanwendungen zu garantieren. Doch...
Mit Microservice-Architectures hat sich eine relativ neue Art etabliert, komplexe Anwendungen zu strukturieren. Statt ein großes Quellcode-Ungetüm frei zu lassen, baut man ein Programm aus vielen in sich geschlossenen Services auf. Damit verbunden ist auch eine Umstrukturierung der Arbeitsabläufe im Sinne des agilen Projektmanagements. Warum ist das sinnvoll? Wir erklären, wie Microservices...
Anwendungen im Web benötigen Schnittstellen, um Daten austauschen zu können. Wenn Sie also selbst ein Webprojekt betreiben und anderen Programmen den Zugriff auf bestimmte Datensätze gewähren wollen, ist ein solches API (Application Programming Interface) unverzichtbar. Häufig wird bei der Entwicklung auf etablierte Konzepte wie REST oder SOAP zurückgegriffen – alternativlos sind diese jedoch...
Mit Continuous Delivery automatisieren Software-Entwickler den Prozess von Entwicklung, Qualitätssicherung, Testing, Produktion und Auslieferung. Dabei erhalten sie die Möglichkeit, eine Software in einem viel früheren Entwicklungsstadium an den Kunden auszuliefern, während an dem Programm noch weitergearbeitet wird. Die dafür nötige Continuous Delivery Pipeline wird in unterschiedliche Testphasen...
Schnell, sicher und State-of-the-Art – nutzen Sie unsere starke Plattform für Ihre Kunden
