REST ist ein Architekturstil, der auf vernetzte Anwendungen angewendet wird. Es handelt sich um eine Reihe von Einschränkungen, die auf die Implementierung von Netzwerkkomponenten angewandt werden und eine einheitliche Schnittstellensemantik anstelle von anwendungsspezifischen Implementierungen und Syntax ermöglichen.
REST als Netzwerkarchitektur wurde erstmals von Roy Fielding in seiner im Jahr 2000 veröffentlichten Doktorarbeit mit dem Titel Architectural Styles and the Design of Network-based Software Architectures dokumentiert. REST ermöglicht es den Clients, mit den auf einem Server gespeicherten Daten zu interagieren, ohne dass sie den Server oder die darauf befindlichen Daten vorher kennen müssen.
REST steht für Representational State Transfer. Akronym-Puristen schreiben es oft als ReST, weil das E in REST eigentlich für nichts steht. Es ist lediglich der zweite Buchstabe des Wortes Representational. Dadurch wird eine Kontroverse über die Aussprache vermieden, wie sie in den letzten Jahren bei GIF aufgetreten ist. Mit dem enthaltenen E gibt es keine Verwirrung bei der Aussprache des korrekteren Akronyms RST als "Handgelenk" oder sogar als R-S-T.
Mit benutzerdefinierten Warnmeldungen und Datenvisualisierung können Sie Probleme mit dem Zustand und der Leistung Ihres Netzwerks schnell erkennen und vermeiden.
Es gibt keine spezifische Definition oder Norm dafür, was REST ist. Als Architektur definiert REST, wie verschiedene Komponenten über Konnektoren verbunden werden und wie Daten über Schnittstellen ausgetauscht werden. REST ist eine Reihe von Einschränkungen oder Anforderungen, die, wenn sie befolgt werden, eine Implementierung des REST-Architekturstils ergeben.
Die REST-Architektur fördert nicht die Entwicklung zusätzlicher, situationsspezifischer Methoden. Eine REST-Architektur würde beispielsweise in jedem Fall die GET-Methode zum Abrufen von Daten verwenden. Die einzige Änderung für unterschiedliche Datentypen wären unterschiedliche Parameter. Dies steht im Gegensatz zur Erstellung einer neuen Methode zum Abrufen von Informationen über einen Benutzer (getUser) und einer weiteren Methode zum Abrufen von Informationen über Preise (getPricing) und so weiter.
Die Benutzeroberfläche auf dem Client ist getrennt und unabhängig von der Datenspeicherung auf dem Server. Dadurch kann der Client implementiert und geändert werden, unabhängig davon, was auf dem Server geschieht oder nicht geschieht. Ebenso können die Daten auf dem Server genutzt und geändert werden, unabhängig davon, wie der Client auf sie zugreift. Ein solches Design ermöglicht es sowohl dem Client- als auch dem Serversystem, sich unabhängig voneinander in ihrem eigenen Tempo weiterzuentwickeln.
Zwischen den Anfragen des Clients sollten keine Sitzungsdaten auf dem Server gespeichert werden. Mit anderen Worten: Jede Transaktion muss die Fähigkeit mit sich bringen, die Anfrage vollständig zu verstehen, ohne auf zusätzlichen Kontext oder Daten auf dem Server zugreifen zu müssen. Alle Sitzungsdaten sollten sich ausschließlich auf dem Client befinden.
Diese Einschränkung ermöglicht einen vereinfachten Lastenausgleich oder Fehlertoleranz. Ein anderer Server könnte auf jede einzelne Anfrage eines Clients antworten und die gleichen Daten wie der ursprüngliche Server zurückgeben, solange beide Server über die gleichen ursprünglichen Daten verfügen. Es besteht keine Notwendigkeit, sitzungsspezifische Daten zwischen solchen Servern für den Lastenausgleich zu übertragen. Sitzungen, die nicht zustandslos sind, können zu unterschiedlichen Antworten führen, wenn die Anfrage von einem anderen Server bearbeitet wird, da nur der vorherige Server über Daten verfügt, die für diese Sitzung mit dem Client spezifisch sind.
Bei jedem Exchange müssen Daten entweder als cachefähige oder nicht cachefähige Daten gekennzeichnet werden. Daten, die zwischengespeichert werden können, können vom Client gespeichert und wiederverwendet werden. Auf dem Server werden keine Daten zwischengespeichert, da dies gegen die zustandslose Beschränkung verstoßen würde. Die Möglichkeit, Daten zu cachen, reduziert die erhöhte Bandbreite, die sonst zur Aufrechterhaltung einer zustandslosen Client-Server-Sitzung erforderlich ist.
Um eine vollständige Interoperabilität zu erreichen, ist die Schnittstelle von der Art der Daten entkoppelt, sofern alle Interaktionen auf dieselbe Weise ablaufen. Vier Teilbedingungen sorgen für einheitliche Schnittstellen: Identifizierung von Ressourcen, Manipulation von Ressourcen über Darstellungen, selbstbeschreibende Nachrichten und Hypermedia als Motor des Anwendungszustands (HATEOAS).
Jede Information, die benannt werden kann, ist eine Ressource. Eine Ressource kann jede Form von Daten sein. Eine Ressourcenkennung ist eine Möglichkeit, auf eine bestimmte Ressource zu einem bestimmten Zeitpunkt zu verweisen. Solche Ressourcen können auf dem Server aktualisiert werden, ohne dass der Client über Vorwissen verfügen muss, da jede Anfrage vollständig beschrieben und beantwortet wird.
Eine Repräsentation ist der aktuelle Zustand einer Ressource, zusammen mit den dazugehörigen Metadaten, die das Verständnis der Repräsentation ermöglichen. Das Datenformat einer Darstellung definiert ihren Medientyp. So kann ein Client eine Ressource, z. B. ein Bild, von einem Server unter Verwendung der Ressourcenkennung dieser Ressource (wahrscheinlich ein URI) anfordern, und eine Darstellung dieses Bildes, die aus den Bytes besteht, aus denen das Bild zusammengesetzt ist, wird zusammen mit den Metadaten, die das Datenformat als Medientyp JPG definieren, an den Client zurückgegeben, der dann das Bild dem Benutzer anzeigen kann.
Jede Nachricht vom Client an den Server muss alle Informationen enthalten, die zur Verarbeitung der Nachricht erforderlich sind. Im Falle der Sicherheit und der Authentifizierung muss das Security Token in jeder Nachricht ausgetauscht werden.
Cookies sind im Internet sehr beliebt. Die Überprüfung des Cookies gegenüber allen Daten in jeder Nachricht wäre ein Beispiel für eine nicht selbstbeschreibende Nachricht und somit technisch gesehen nicht RESTful.
Definition von Hypermedia
Hypermedia ähnelt dem Konzept des Hypertextes oder der Hyperlinks, mit dem Unterschied, dass es alle Formen von Medien umfasst und nicht nur Text oder Links. Es handelt sich um eine nicht-lineare Art der Bereitstellung von Informationen oder Daten, die in der Regel über einen Link oder eine andere Markierung in einer veröffentlichten Ressource, wie z. B. einer Web-Seite, erfolgt. Hypermedia kann aus Text, Grafik, Video oder anderen Datenformen bestehen.
Bei HATEOAS interagiert ein Client über ein Netzwerk durch Hypermedia
Der Client interagiert mit einem Server ausschließlich über Hypermedia. Dieselben Hypermedien werden vom Server als Antwort auf eine RESTful-Anfrage dynamisch bereitgestellt. Folglich sind keine Vorkenntnisse über die Daten auf einem Server, ihre Struktur oder die Art ihrer Speicherung erforderlich. Stattdessen müssen nur wohldefinierte Hypermedia-Strukturen und -Methoden verwendet werden.
In einem System mit hierarchischen Schichten kann keine Komponente mit Daten oder Schnittstellen interagieren oder diese sehen, außer auf ihrer eigenen unmittelbaren Schicht. Folglich muss der Client nicht wissen, wie er sich mit einem zusätzlichen Server, Proxy, einer Firewall, einem Router oder einem Endpunkt verbinden kann oder ob dies überhaupt notwendig ist. Vielmehr wird jeder Vermittler weiterhin eine Verbindung zu den nachfolgenden Servern gemäß den REST-Bedingungen herstellen, und die daraus resultierende Antwort auf jede Anfrage, die über die Vermittler an den Client zurückgegeben wird, wird ebenfalls REST-konform sein. Änderungen oder Unterbrechungen der zwischengeschalteten Systeme sind daher für den Kunden unsichtbar, so dass diese zwischengeschalteten Systeme für den Lastenausgleich, die Sicherheit oder andere Funktionen sorgen können.
Obwohl technisch als optional bezeichnet, sollten Clients in einer REST-Architektur in der Lage sein, Skripte herunterzuladen und auszuführen. Dies ermöglicht die Erweiterung komplizierterer Funktionen und Systeme, während gleichzeitig die gleiche REST-artige Kommunikation zwischen Client und Server gewährleistet ist. Wie bei den grundlegenden Anfragen und Antworten muss die gesamte Anweisung zur Ausführung des Skriptcodes unabhängig sein und keine Vorimplementierung auf dem Client erfordern.
So kann ein Web-Client beispielsweise JavaScript ausführen, das er vom Server erhält. Der Code befindet sich zwar auf dem Server, wird dort aber nicht ausgeführt. Stattdessen wird der Code selbst als Teil der Anfrage an den Client gesendet, und dieser Code wird vom Client entsprechend seiner Implementierung ausgeführt. Aus diesem Grund ist die ordnungsgemäße Implementierung von Standards in Web-Clients so wichtig; andernfalls kann derselbe Code vom Server auf verschiedenen Clients mit unterschiedlichen Ergebnissen ausgeführt werden.
Benachrichtigungen in Echtzeit bedeuten eine schnellere Fehlerbehebung, so dass Sie handeln können, bevor ernstere Probleme auftreten.
Die Komponenten eines REST-Systems kommunizieren über eine Darstellung einer Ressource in einem von mehreren vereinbarten standardisierten Formaten wie Grafikformaten, Dokumentenformaten und verschiedenen Webformaten. Um ein echtes REST-System zu sein, muss jede Transaktion die Fähigkeit enthalten, die gewünschte Ressource abzurufen und zu interpretieren.
Eine Ressource ist alles, was benannt werden kann. Die auf dem Server gespeicherte Ressource, die vom Client angefordert wird. Eine Ressource kann eine statische Datei, ein Dokument, eine Datenbank, ein Bild oder ein anderes Format sein, das angefordert werden kann.
Die ursprüngliche Idee einer Ressource als generisches, änderbares, zeitlich begrenztes Element war ein Schlüsselmerkmal von REST und des Webs im Allgemeinen, auch wenn dies heute ein gängiges Konzept ist. Eine Ressource ist ein beliebiger benennbarer Datensatz auf einem Server. Diese Daten können sich nicht nur in eine neuere Version derselben Daten, sondern sogar in einen völlig anderen Datentyp ändern. Auf diese Weise können die Daten auf einem Server jederzeit aktualisiert werden, ohne dass ein Client im Voraus darüber Bescheid wissen muss - ein Schlüsselmerkmal für Interoperabilität und Verfügbarkeit.
Der Ressourcen-Identifikator ist der spezifische Ort der angeforderten Ressource. Im Falle eines HTTP-basierten Systems ist der Ressourcenbezeichner die URL oder URI. Der Ressourcen-Identifikator spezifiziert eine einzelne Ressource. Ein einzelner Ressourcenbezeichner kann sich zu verschiedenen Zeiten auf unterschiedliche Daten oder Ressourcen beziehen. In einem REST-konformen System muss der Client nicht im Voraus wissen, welche Art von Ressource der Ressourcenbezeichner anfordert. Die Antwort enthält Metadaten, die beschreiben, wie die empfangenen Daten zu interpretieren sind.
Wenn beispielsweise eine URL-Abfrage /server/index.html lautet und die Ressource an dieser Adresse eine Darstellung als Bilddatei zusammen mit den entsprechenden Metadaten zurückgibt, wird die Bilddatei unabhängig von der Angabe der Ressourcenkennung korrekt angezeigt.
Dies bezieht sich auf die Daten, die an den Client gesendet werden. Wie bereits erwähnt, muss die Darstellung in einem der standardisierten Datenformate erfolgen. Die Daten werden nicht auf dem Server verarbeitet, sondern vom Client interpretiert. Ein Client, der beispielsweise ein HTML-Dokument anfordert, erhält keine Grafik, die auf dem Monitoring angezeigt wird, sondern einen Satz HTML-Code, der dann interpretiert und auf dem Client angezeigt wird. Andere Beispiele für Darstellungen sind Grafikdateien wie JPEG- und GIF-Bilder.
Darstellungsmetadaten stellen dem System Informationen über die Darstellung zur Verfügung. Wie die meisten Metadaten sind auch die Darstellungsmetadaten in der Regel nicht Teil des Inhalts, der dem Endbenutzer angezeigt wird. Zu den Darstellungsmetadaten können der Medientyp, das Erstellungs- und Änderungsdatum sowie die Versionsnummer gehören.
Ressourcen-Metadaten sind zusätzliche Informationen, die dem System über die Ressource zur Verfügung gestellt werden, die auf dem Server und nicht in der auf dem Client angezeigten Darstellung existiert. Beispiele für Ressourcen-Metadaten sind Quelllinks, Alternativen und Informationen über die Ressource. Zu den Ressourcen-Metadaten kann beispielsweise alternativer Text gehören, der angezeigt wird, wenn eine Bilddarstellung aus irgendeinem Grund nicht angezeigt werden kann (z. B. ALT-Bildtext in HTML).
Bei den Kontrolldaten geht es in erster Linie um die Gültigkeit der Ressource und ihrer Darstellung auf dem Client. Zu den Kontrolldaten gehört die Angabe, ob die Daten zwischengespeichert werden können oder nicht, sowie die absolute Ablaufzeit oder eine Begrenzung der Nutzungsdauer der Daten. Kontrolldaten können auch eine Prüfsumme oder ein anderes Mittel zur Gewährleistung der Integrität enthalten.
Zusammengenommen schafft die REST-Architektur einen hochskalierbaren, völlig transparenten und wiederverwendbaren Rahmen, in dem die Clients von der Implementierung der Dienste auf den Servern entkoppelt sind. Sie ist plattformunabhängig, sowohl für den Client als auch für den Server. Es ist sprach- und strukturunabhängig. Es spielt keine Rolle, ob die Daten in einer Datenbank vorhanden sind, von einem Java-Serverprozess abgerufen und an ein lokales Programm - z. B. einen Browser - gesendet werden, das in einer von mehreren Versionen von C codiert ist.
Im modernen Web wird REST unter Verwendung eines gemeinsamen Standardvokabulars zwischen Client und Server, dem Hypertext Transfer Protocol (HTTP), implementiert. Als RESTful-Implementierungen gelten jedoch alle Implementierungen, die allen Anforderungen der REST-Architektur genügen. HTTP ist nicht die einzige Möglichkeit.
Obwohl HTTP und REST nicht dasselbe sind, ist HTTP in seiner ursprünglichen Form eine Implementierung von REST. Dies ist nicht verwunderlich, wenn man bedenkt, dass Roy Fielding während der Entwicklung der REST-Architektur an dem Protokoll HTTP 1.1 arbeitete.
Jede Ressource wird durch einen Uniform Resource Identifier (URI) identifiziert. In der Regel wird dies als URL in einem Webbrowser implementiert. Ein URI identifiziert eine Ressource. Es sind keine Vorkenntnisse über das System erforderlich, in dem sich die Ressource auf dem Server befindet. Außerdem kann der URI (oder URL) die Darstellung einer Ressource angeben, ohne dass die Dateistruktur dieser Ressource bekannt ist.
In HTTP wird die Darstellung von Ressourcen durch die Unterstützung verschiedener Dateitypen in einem HTTP-Browser realisiert. Die Metadaten, die eine Ressource begleiten, definieren also eines von mehreren weithin unterstützten Dateiformaten wie HTML, CSS, JPG, GIF und so weiter.
Eine reine REST-Implementierung von HTTP erfordert die Verwendung der vier Kernmethoden GET, POST, PUT und DELETE. Jede Methode sollte explizit verwendet und jeweils auf eine der Kernaktionen RETRIEVE DATA, CREATE RESOURCE, UPDATE RESOURCE und DELETE RESOURCE gemappt werden.
Bestimmte HTTP-Methoden sollten idempotent sein. Idempotent bedeutet, dass die Ausführung der gleichen Methode mit den gleichen Parametern immer das gleiche Ergebnis liefern sollte. Damit dies funktioniert, darf die betreffende Methode keine Änderungen auf dem Server verursachen, die dazu führen würden, dass für dieselbe Anfrage ein anderes Ergebnis zurückgegeben wird. In der Praxis sollte eine idempotente Anfrage keine Server-basierten Daten verändern.
Wird verwendet, um eine Ressource oder Informationen über die Ressource abzurufen. Obwohl die meisten HTTP-Implementierungen Parameter mit einer GET-Anforderung verarbeiten, um Ressourcen zu ändern oder zu erstellen, würde eine solche Aktion nicht mit einer RESTful-Implementierung übereinstimmen. GET-Anfragen sollten idempotent sein.
Eine POST-Anfrage erzeugt neue Daten auf einem Server. Per Definition ist eine POST-Anfrage NICHT idempotent. Bei jeder Ausführung würde eine POST-Anfrage mehr Daten erzeugen.
Ähnlich wie bei einer POST-Anfrage werden bei einer PUT-Anfrage vorhandene Daten geändert. Zum Beispiel wird der Nachname eines bestehenden Benutzers geändert. PUT-Anfragen sind nicht intuitiv idempotent. Eine PUT-Anfrage ändert zwar Daten, aber jedes Mal auf die gleiche Weise. Eine PUT-Anforderung, die den Nachnamen eines Benutzers ändert, würde also immer das gleiche Ergebnis liefern, solange alle Parameter konsistent sind.
Eine DELETE-Anforderung entfernt oder löscht, wie der Name schon sagt, Daten. Löschanfragen sind ebenfalls idempotent, da die wiederholte Ausführung einer solchen Anfrage immer zum gleichen Endzustand führt, bei dem die betreffenden Daten nicht mehr auf dem Server vorhanden sind. Für den Client mag jedoch der Unterschied bestehen, dass die Anfrage nach dem Löschen einer Ressource mit einer Fehlermeldung wie "Datei nicht gefunden" beantwortet werden kann. Die Methode gilt jedoch immer noch als idempotent, da der Endzustand einer solchen Anfrage unabhängig von der Fehlermeldung während der Transaktion derselbe ist wie bei der ersten Anfrage.
PRTG ist eine umfassende Monitoring-Software für Netzwerke und überwacht Ihre gesamte IT-Infrastruktur.
In einem Blogbeitrag in seinem inzwischen eingestellten Blog hat Roy Fielding erörtert, welche Kriterien eine API erfüllen muss, um als wirklich RESTful zu gelten. Aufbauend auf seiner zuvor veröffentlichten These beschrieb er in diesem Beitrag die gleichen Konzepte der REST-Architektur, wie sie auch für APIs gelten sollten.
Eine RESTful API ist demnach eine API, die NUR die REST-Architektur verwendet, ohne dass zusätzliche Dokumentation oder Methoden erforderlich sind, die über die hinausgehen, die dem Modell entsprechen. Fielding stellte die folgenden Punkte zur Verfügung, um zu verdeutlichen, was eine API REST-konform macht.
Eine wirklich RESTful API sollte nicht von einem bestimmten Protokoll abhängig sein und jedes Protokoll unterstützen können, das URI zur Identifizierung verwendet. Andernfalls ist die Identifizierung nicht von der Interaktion getrennt.
Eine REST API sollte keine Änderungen an standardisierten Protokollen erfordern, insbesondere keine Hinzufügung von zusätzlichen Funktionen. Wann immer möglich, sollten erforderliche Umgehungen separat definiert werden, mit dem Ziel, sie ganz zu entfernen, sobald die Umgehungen nicht mehr erforderlich sind.
Ein Server-Namensraum sollte unabhängig von der API-Definition und den Anforderungen sein. Mit anderen Worten: Die API sollte mit jedem REST-fähigen Server funktionieren, nicht nur mit Servern, die einer bestimmten API-Spezifikation entsprechen.
