Es handelt sich dabei also nicht um den fast gleichnamigen fiktiven Supercomputer HAL 9000. Den man aus dem Science-Fiction-Roman „2001: Odyssee im Weltraum“ von Arthur C. Clarke oder dem gleichnamigen Film von Stanley Kubrick aus dem Jahr 1968 kennt ;).

Es steht für „Hypertext Application Language“ und basiert auf dem HATEOAS (Hypermedia as the Engine of Application State)-Konzept. Das Ziel von HAL ist es, eine einheitliche Methode zum Beschreiben von APIs bereitzustellen. Gleichzeitig soll sie die Interoperabilität zwischen verschiedenen Systemen und Plattformen verbessern.

Im Wesentlichen besteht ein HAL-Dokument aus zwei Teilen: Ressourcen und Links. Eine Ressource ist eine Datenstruktur, die Informationen über eine bestimmte Entität enthält. Links sind Beziehungen zwischen Ressourcen, die es einem Client ermöglichen, auf eine andere Ressource zuzugreifen. Ein Link enthält normalerweise einen URI (Uniform Resource Identifier). Dieser hat eine eindeutige Adresse für eine Ressource, die sie bereitstellt und einen Relationstyp. Dieser beschreibt, welche Beziehung die verknüpfte Ressource zur aktuellen Ressource hat.

Ein typisches HAL-Dokument ist ein simples JSON [RFC7159] und kann folgendermaßen aussehen:

{
  "_links": {
    "self": { "href": "/api/book/123" },
    "author": { "href": "/api/author/456" }
  },
  "title": "2001: Odyssee im Weltraum",
  "authorName": "Arthur C. Clarke",
  "publishedDate": "1968"
}

In diesem Beispiel enthält das HAL-Dokument eine Ressource, die Informationen über ein Buch enthält, sowie Links zu anderen Ressourcen. Beispielsweise dem Autor des Buches. Der Link mit dem Relationstyp „self“ gibt an, dass der Link auf die aktuelle Ressource verweist. Während der Link mit dem Relationstyp „author“ angibt, dass der Link auf den Autor des Buches verweist.

Ein wichtiger Aspekt des HAL-Formats ist, dass es HATEOAS unterstützt. Dies bedeutet, dass alle Ressourcen in einer API durch Links miteinander verbunden sind. Dadurch kann ein Client einer API eine Ressource abrufen und im Anschluss die verfügbaren Links verwenden, um weitere Aktionen auszuführen. Beispielsweise das Abrufen von verwandten Ressourcen oder das Ausführen von Aktionen auf einer Ressource. Dadurch kann man die Flexibilität und Erweiterbarkeit einer API verbessern. Weil man eben neue Ressourcen und Aktionen hinzufügen kann, ohne dass Änderungen am Client-Code erforderlich sind.

Fazit

Insgesamt ist der HAL-Standard eine nützliche Methode zur Beschreibung von APIs. Es gewährleistet eine gute Interoperabilität zwischen verschiedenen Systemen, steigert die Flexibilität und Erweiterbarkeit einer API.

Der Beitrag HAL-Standard – Effiziente Hypermedia-APIs für nahtlose Web-Service-Interaktionen und erweiterbare Systeme erschien zuerst auf CEOsBay.

Es beschreibt unter anderem eines der wichtigsten REST-Eigenschaften. Da der Architekturstil eine universelle Schnittstelle bieten soll, fordert HATEOAS, 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 Anwendung bzw. dem Server zu kommunizieren.

Die Bereitstellung der einzelnen URIs erfolgt dabei beispielsweise in Form von href- und src-Attributen. Vorausgesetzt es handelt sich um HTML-Dokumente oder -Snippets. Auch durch JSON– bzw. XML-Attribute/-Elemente, die der jeweilige Client automatisch erkennt.

Durch die Umsetzung des HATEOAS-Prinzips lässt sich die Schnittstelle eines REST-Services jederzeit anpassen. Dies kann ein wichtiger Vorteil dieser Architektur gegenüber anderen Applikationsstrukturen sein. Vor allem im direkten Vergleich mit Anwendungen, die man auf Grundlage von SOAP (Simple Object Access Protocol) ausführt.

Das HATEOAS-Konzept ist wichtig, weil es die Flexibilität und Skalierbarkeit von RESTful APIs verbessert. Ohne HATEOAS müsste ein Client spezifische URLs und Endpunkte kennen, um eine Anwendung effektiv zu nutzen. Dies kann jedoch kritisch sein, da URLs sich in der Regel ändern können. Diese Tatsache kann jedoch eben auch zu Fehlern und fehlerhaften Anfragen führen.

Durch die Verwendung von Hypertext-Links wird ein Client in die Lage versetzt, den aktuellen Zustand der Anwendung zu verstehen und dynamisch zu navigieren. Wenn beispielsweise ein Client eine Anfrage an den Server sendet, um eine Liste von Benutzern abzurufen, könnte der Server eine Antwort zurückgeben, die Links zu den einzelnen Benutzerdetails enthält. Der Client kann dann den Link zu einem bestimmten Benutzer folgen, um weitere Informationen abzurufen.

Ein Beispiel ist eine Bestellungsverwaltung in einem Online-Shop. Wenn ein Kunde eine Bestellung aufgeben möchte, kann der Server eine Antwort zurückgeben. Die enthalten wiederum Links zu den verschiedenen Schritten des Bestellvorgangs. Um beispielsweise den Warenkorb anzuzeigen, die Versandadresse anzugeben, Zahlungsinformationen anzugeben, etc. Der Client kann dann den Link zum nächsten Schritt folgen, ohne spezifische URLs oder Endpunkte zu kennen.

HATEOAS ist jedoch nicht nur für die Navigation innerhalb einer Anwendung wichtig. Es ermöglicht auch eine einfache Integration mit anderen Anwendungen und Diensten. Wenn eine API beispielsweise HATEOAS-konform ist, kann man sie von anderen Anwendungen oder Diensten aus leichter nutzen, da sie den Zustand der Anwendung und die verfügbaren Aktionen verstehen können.

Fazit

Insgesamt verbessert das HATEOAS-Konzept die Flexibilität und Skalierbarkeit von RESTful APIs, indem es Clients in die Lage versetzt, dynamisch zu navigieren und den aktuellen Zustand der Anwendung zu verstehen. Durch die Verwendung von Hypertext-Links werden Anwendungen leichter integrierbar und besser wartbar. Wenn man also eine RESTful API entwirft, sollte man in Betracht ziehen, HATEOAS zu verwenden, um die Nutzbarkeit und die Flexibilität der Anwendung zu optimieren.

Der Beitrag HATEOAS – Evolution von REST für selbsterklärende APIs und zukunftssichere Web-Anwendungen erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.