AUSRUHEN

REST ( Representational State Transfer ) ist ein Softwarearchitekturstil , der entwickelt wurde, um den Entwurf und die Entwicklung der Architektur des World Wide Web zu beschreiben . REST definiert eine Reihe von Anforderungen an das Verhalten der Architektur eines verteilten Hypermediasystems im Internetmaßstab , wie beispielsweise des Webs. Der REST-Architekturstil betont einheitliche Schnittstellen , die unabhängige Bereitstellung von Komponenten , die Skalierbarkeit der Interaktionen zwischen ihnen und die Schaffung einer geschichteten Architektur , um Caching zur Reduzierung der wahrgenommenen Latenz für den Benutzer zu fördern , die Sicherheit zu gewährleisten und bestehende Systeme zu kapseln . ^{[ 1 ]}

REST wird in der gesamten Softwareindustrie eingesetzt, um zustandslose , zuverlässige, webbasierte Anwendungen zu erstellen . Eine Anwendung, die den Architekturvorgaben von REST entspricht, kann informell als RESTful bezeichnet werden , obwohl dieser Begriff häufiger mit dem Design von HTTP -basierten APIs und allgemein anerkannten Best Practices bezüglich der „Verben“ ( HTTP-Methoden ) in Verbindung gebracht wird, auf die eine Ressource reagiert. Dies hat wenig mit der ursprünglichen Formulierung von REST zu tun – und steht oft sogar im Widerspruch zu diesem Konzept. ^{[ 2 ]}

Der Begriff „Representational State Transfer“ (RST) wurde im Jahr 2000 von dem Informatiker Roy Fielding in seiner Doktorarbeit eingeführt und definiert. Er besagt, dass ein Server mit der Repräsentation einer Ressource antwortet (heutzutage meist ein HTML- Dokument). Diese Ressource enthält Hypermedia- Links, über die der Systemzustand geändert werden kann. Jede solche Anfrage empfängt wiederum die Repräsentation einer Ressource usw.

Eine wichtige Konsequenz ist, dass nur die Kennung der ersten angeforderten Ressource bekannt sein muss; alle weiteren Kennungen werden automatisch ermittelt. Das bedeutet, dass sich diese Kennungen ändern können, ohne dass der Client vorher informiert werden muss, und dass Client und Server zwangsläufig lose gekoppelt sein müssen .

Das Web hielt 1993/94 Einzug in den Alltag, als Websites für den allgemeinen Gebrauch verfügbar wurden. ^{[ 3 ]} Damals existierte nur eine fragmentarische Beschreibung der Webarchitektur, und innerhalb der Community gab es Druck, sich auf einen Standard für die Webschnittstellenprotokolle zu einigen. Beispielsweise wurden dem Kommunikationsprotokoll (HTTP) mehrere experimentelle Erweiterungen zur Unterstützung von Proxys hinzugefügt , und weitere Erweiterungen wurden vorgeschlagen. Es bestand jedoch Bedarf an einer formalen Webarchitektur, mit der die Auswirkungen dieser Änderungen bewertet werden konnten. ^{[ 4 ]}

Die Arbeitsgruppen des W3C und der IETF begannen gemeinsam mit der Erstellung formaler Beschreibungen der drei wichtigsten Webstandards: URI , HTTP und HTML . Roy Fielding war an der Entwicklung dieser Standards (insbesondere HTTP 1.0 und 1.1 sowie URI) beteiligt und entwickelte in den folgenden sechs Jahren den REST-Architekturstil. Er testete dessen Einschränkungen anhand der Webprotokollstandards und nutzte ihn, um architektonische Verbesserungen zu definieren und architektonische Diskrepanzen aufzudecken. Fielding definierte REST in seiner Dissertation „Architectural Styles and the Design of Network-based Software Architectures“ ^{[ 1 ] [ 5 ],} die er 2000 an der UC Irvine einreichte .

Um den REST-Architekturstil zu entwickeln, identifizierte Fielding die Anforderungen an die Erstellung einer globalen, netzwerkbasierten Anwendung, beispielsweise die Notwendigkeit niedriger Einstiegshürden für eine weltweite Akzeptanz. Er untersuchte zudem zahlreiche bestehende Architekturstile für netzwerkbasierte Anwendungen und ermittelte Gemeinsamkeiten wie Caching und Client-Server-Architektur sowie REST-spezifische Merkmale wie das Ressourcenkonzept. Fielding verfolgte das Ziel, die bestehende Architektur der aktuellen Implementierung zu kategorisieren und die zentralen Aspekte für die Verhaltens- und Leistungsanforderungen des Webs zu identifizieren.

Architekturstile sind naturgemäß unabhängig von einer konkreten Implementierung. Obwohl REST im Rahmen der Entwicklung der Webstandards entstanden ist, hält sich die Webimplementierung nicht an alle Vorgaben des REST-Architekturstils. Abweichungen können aufgrund von Unwissenheit oder Nachlässigkeit auftreten, doch dank des REST-Architekturstils lassen sie sich erkennen, bevor sie standardisiert werden. Fielding identifizierte beispielsweise das Einbetten von Sitzungsinformationen in URIs als Verstoß gegen die REST-Vorgaben, da dies die gemeinsame Zwischenspeicherung und die Server-Skalierbarkeit beeinträchtigen kann. Auch HTTP-Cookies verstoßen gegen die REST-Vorgaben ^{[ 4 ]} , da sie mit dem Anwendungsstatus des Browsers nicht mehr synchron sein können und somit unzuverlässig werden. Zudem enthalten sie undurchsichtige Daten, die Datenschutz- und Sicherheitsrisiken bergen .

Der REST-Architekturstil ist für netzwerkbasierte Anwendungen, insbesondere Client-Server-Anwendungen, konzipiert. Darüber hinaus ist er für den Einsatz im Internetmaßstab ausgelegt, weshalb die Kopplung zwischen Benutzeragent (Client) und Ursprungsserver so locker wie möglich sein muss , um eine breite Akzeptanz zu ermöglichen.

Die starke Entkopplung von Client und Server sowie die textbasierte Informationsübertragung mittels eines einheitlichen Adressierungsprotokolls bildeten die Grundlage für die Erfüllung der Anforderungen des Webs: Erweiterbarkeit , anarchische Skalierbarkeit ^{[ 6 ]} und unabhängige Bereitstellung von Komponenten, grobkörnige Datenübertragung und eine niedrige Einstiegshürde für Leser, Autoren und Entwickler.

Die Einschränkungen des REST-Architekturstils beeinflussen die folgenden Architektureigenschaften: ^{[ 1 ] [ 7 ]}

• Die Leistung bei der Interaktion der Komponenten kann der dominierende Faktor für die vom Benutzer wahrgenommene Leistung und die Netzwerkeffizienz sein; ^{[ 8 ]}
• Skalierbarkeit, die die Unterstützung einer großen Anzahl von Komponenten und Interaktionen zwischen den Komponenten ermöglicht;
• Einfachheit einer einheitlichen Schnittstelle;
• Modifizierbarkeit ( auch Erweiterbarkeit genannt ) von Komponenten, um sich ändernden Anforderungen gerecht zu werden (auch während die Anwendung läuft);
• Sichtbarkeit der Kommunikation zwischen den Komponenten durch Serviceagenten;
• Portabilität von Komponenten durch Verschieben des Programmcodes zusammen mit den Daten;
• Zuverlässigkeit bedeutet Widerstandsfähigkeit gegen Ausfälle auf Systemebene bei Ausfällen innerhalb von Komponenten, Steckverbindern oder Daten. ^{[ 8 ]}

The REST architectural style defines six guiding constraints.^[7][9] When these constraints are applied to the system architecture, it gains desirable non-functional properties, such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability.^[1]

The formal REST constraints are as follows:^[10]

• Client/Server – Clients are separated from servers by a well-defined interface
• Stateless – A specific client does not consume server storage when the client is "at rest"
• Cache – Responses indicate their own cacheability
• Uniform interface
• Layered system – A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way
• Code on demand (optional) – Servers are able to temporarily extend or customize the functionality of a client by transferring logic to the client that can be executed within a standard virtual machine

The uniform interface constraint is fundamental to the design of any RESTful system.^[1] It simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints for this uniform interface are:

• Resource identification in requests: Individual resources are identified in requests using URIs. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server could send data from its database as HTML, XML or as JSON—none of which are the server's internal representation.
• Resource manipulation through representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource's state.
• Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.^[1]
• Hypermedia as the engine of application state (HATEOAS) – Having accessed an initial URI for the REST application—analogous to a human Web user accessing the home page of a website—a REST client should then be able to use server-provided links dynamically to discover all the available resources it needs. As access proceeds, the server responds with text that includes hyperlinks to other resources that are currently available. There is no need for the client to be hard-coded with information regarding the structure of the server.^[11]

Es wurden mehrere Modelle entwickelt, um HTTP-APIs anhand ihrer Einhaltung verschiedener REST-Designprinzipien zu klassifizieren, wie zum Beispiel

• das Richardson-Reifegradmodell
• Klassifizierung von HTTP-basierten APIs ^{[ 12 ]}
• das WS ^3- Reifegradmodell ^{[ 13 ]}

• Saubere URL  – Eine URL, die die Benutzerfreundlichkeit einer Website verbessern soll.
• Content Delivery Network  – eine Schicht des Internet-Ökosystems, die Engpässe beseitigt.
• Domänenanwendungsprotokoll (DAP)
• Liste der URI-Schemata  – Namespace-Kennung, die von der IANA vergeben wird
• Mikrodienste  – Sammlung lose gekoppelter Dienste zur Erstellung von Computeranwendungen
• Überblick über RESTful API-Beschreibungssprachen  – Beschreibungen von Computersprachen
• Ressourcenorientierte Architektur  – Architekturmuster im Software-Design
• Ressourcenorientiertes Rechnen  – Architekturmuster im Software-Design
• Serviceorientierte Architektur  – Architekturmuster im Software-Design
• Weborientierte Architektur  – Architekturmuster im Software-Design
• Webdienst  – Ein Dienst, der zwischen elektronischen Geräten über das Internet angeboten wird.

• Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: Advanced Research Topics and Practical Applications , Springer, ISBN 9781461492986
• Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (April 2008), „RESTful Web Services vs. „Big“ Web Services“, Proceedings of the 17th International Conference on World Wide Web , S.  805–814 , doi : 10.1145/1367497.1367606 , ISBN 9781605580852, S2CID  207167438
• Ferreira, Otavio (November 2009), Semantic Web Services: A RESTful Approach , IADIS, ISBN 978-972-8924-93-5
• Fowler, Martin (18.03.2010). „Richardson-Reifegradmodell: Schritte zum Erfolg von REST“ . martinfowler.com . Abgerufen am 26.06.2017 .