Was ist REST? Teil 1: RESTful-Architekturen

Was ist REST? Teil 1: RESTful-Architekturen

Roy Fielding, einer der Hauptautoren der HTTP-Spezifikation, liefert mit seiner Dissertation die theoretische Grundlage von REST. Basierend auf seiner Arbeit wird in diesem Artikel neben der Motivation hinter REST auch einen Blick auf die wesentlichen Grundprinzipen geworfen.

REST als Architekturstil für das moderne Web

Die berühmte wissenschaftliche Arbeit von Roy Fielding trägt den Namen „Architectural Styles and the Design of Network-based Software Architectures“. Im Abstract führt Fielding REST als ein Architekturstil für Design und Entwicklung im modernen Web ein.

Die Bezeichnung „REpresentational State Transfer“ leitet sich von den Eigenschaften der generischen Schnittstelle ab, welche für die Kommunikation verwendet wird. In einem weiteren Blog-Beitrag werden wir noch detailliert darauf eingehen. An dieser Stelle wollen wir uns mit dem Begriff „Architekturstil“ beschäftigen. Unter einem Architekturstil versteht Fielding hierbei eine Menge von Einschränkungen, welche auf die einzelnen Elemente einer Architektur sowie deren Beziehungen untereinander angewendet werden:

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

Das englische Wort „constraints“ könnte man in diesem Zusammenhang durchaus mit „Eigenschaft“ übersetzten. Wir halten fest: REST ist ein Architekturstil und beschreibt die Eigenschaften der Elemente einer (modernen) Web-Architektur.

Im Fokus steht Hypermedia

Für REST ist Hypermedia von zentraler Bedeutung. Bereits im allerersten Satz seiner Dissertation erwähnt Fielding, dass der Erfolg von Web im Wesentlichen durch seine Eigenschaft als verteiltes Hypermedia-System zu erklären ist:

The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system.

Für Fielding gehören die Begriffe „(modernes) Web“ und „(verteiltes) Hypermedia“ untrennbar zusammen. Bei REST handelt es sich also um ein Architekturstil für ein (Internet skaliertes) verteiltes Hypermedia-System (also eben Web).

Eine Erläuterung für den Begriff „Hypermedia“ sucht man in der Dissertation vergeblich. Dies ist möglicherweise einer der Gründe, warum REST so oft missverstanden wird. Erst Jahre später erklärt Fielding in einem Blog-Beitrag, was er mit Hypertext (gleichbedeutend wie Hypermedia) meint:

When I say hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton) obtains choices and selects actions.

Hypermedia/Hypertext ist also eine Präsentationsform bestehend aus Informationen und Steuerelementen („controls“) mit der Eigenschaft, dass ein menschlicher Benutzer („user“) oder ein Computer-Programm („automation“) dadurch Auswahlmöglichkeiten bekommt und bestimmte Aktionen durchführen kann. Im Web von heute begegnen wir Hypermedia tagtäglich, indem wir auf einer Webseite z. B. auf einen Link klicken und auf eine weitere Webseite weitergeleitet werden oder durch eine Verlinkung ein Dokument aufrufen. Bei Hypermedia geht es in diesem Kontext also darum, die Informationen im Web zu verknüpfen.

Fielding betrachtet Hypermedia als einfaches generisches User-Interface, womit unabhängig von der Informationsquelle und ihrer physikalischen Lokation (z. B. Datenbank oder Webseite, lokale Maschine oder entfernter Webserver) via Links komplexe Zusammenhänge zwischen Informationen abgebildet werden können.

Motivation und Beweggründe

Das Web entstand 1989 in einem Forschungsprojekt in CERN. Die Forscher entwickelten die ersten Spezifikationen für HTTP, URL und HTML. Es gab viele Ideen für die Weiterentwicklung des Webs. Zahlreiche Erweiterungen sind entstanden. Was fehlte, war eine einheitliche Strategie. Schnell wurde klar, dass eine erfolgreiche Weiterentwicklung des Webs ohne Standardisierung nahezu unmöglich ist.

Mit REST wollte man einen Standard entwickeln, welcher die Funktionsweise des Webs beschreibt und als Framework für Entwicklung von Web-Protokollen dienen soll:

(…) the motivation for developing REST was to create an architectural model for how the Web should work, such that it could serve as the guiding framework for the Web protocol standards. REST has been applied to describe the desired Web architecture, help identify existing problems, compare alternative solutions, and ensure that protocol extensions would not violate the core constraints that make the Web successful.

6 Eigenschaften von REST

Eine REST konforme Architektur soll laut Fielding folgende constraints (also Eigenschaften) besitzen:

  • 1. Client-Server: eine Server-Komponente bietet Services an, welche durch Clients angefragt werden. Es handelt sich dabei um ein klassisches „Separation of Concerns“-Prinzip: Client und Server erledigen jeweils unterschiedliche Aufgaben. Im Kontext des Webs fungiert dabei meistens ein Webbrowser als Client. Die Client-Server-Eigenschaft von REST ist jedoch nicht auf Webbrowser beschränkt. Vorteil: Client und Server können unabhängig voneinander entwickelt und deployed werden.

  • 2. Zustandslos (stateless): jede Client-Anfrage soll alle notwendigen Informationen beinhalten, damit Server diese Anfrage verstehen und beantworten können. Es ist nicht erlaubt, dass Server bestimmte Informationen über den Client speichern und diese für die Bearbeitung einer Anfrage verwenden. In diesem Zusammenhang spricht man auch von Application State. Der Client hingegen, kann bestimmte Informationen bei sich speichern und diese mit jeder Anfrage an den Server senden. Bei diesem Vorgehen, welches ausschließlich beim Client liegt, ist von Session State die Rede. Vorteil: Server können besser skalieren und mehrere Clients bedienen.

  • 3. Cache: liefert der Server nach einer vorausgegangenen Anfrage die Daten an den Client, so sollen diese Daten als cacheable oder nicht cacheable markiert werden. Sind die Daten cacheable, so kann der Client sie speichern und bei Bedarf wiederverwenden, ohne erneut beim Server anzufragen. Vorteil: Unnötige Datenübertragungen werden vermieden.

  • 4. Einheitliches Interface (uniform interface): wenn mehrere Clients die Services eines Servers nutzen, so läuft die Kommunikation über Schnittstellen, welche in Ihrer Beschaffenheit gleich sind. Der Server muss je nach Client-Technologie also keine unterschiedlich gearteten Schnittstellen anbieten. Vorteil: die Schnittstelle bleibt entkoppelt von der technischen Implementierung. Nach Fielding ist ein einheitliches Interface die wichtigste Eigenschaft von REST. Die Bedeutung dieser Eigenschaft bedarf einer besonderen Betrachtung, auf die wir in einem anderen Blog-Artikel noch detailliert eingehen werden.

  • 5. Mehrschichtiges System (layered system): hier handelt es sich um eine hierarchische Struktur. Die Komponenten einer Schicht können ausschließlich mit Komponenten der nächst platzierter Schicht kommunizieren. Eine Kommunikation über eine Schicht hinweg ist nicht möglich. Vorteil: Eine Komponente muss lediglich das Interface der Nachbarschicht kennen.

  • 6. Code on Demand: diese ist die einzige optionale Eigenschaft. Der Client kann den Code (z. B. JavaScript) herunterladen und lokal ausführen. Vorteil: die Client-Funktionalität kann erweitert werden, ohne dass ein Client-seitiges Deployment erforderlich ist.

Eine Architektur ist dann REST-konform (also RESTful), wenn die Eigenschaften 1 bis 5 erfüllt werden. Fielding spricht hier auch von Uniform-Layered-Client-Cache-Stateless-Server. Gemeint ist also Uniform (einheitliches Interface) – Layered (mehrschichtiges System) – Client-Cache (zustandlos mit Session State auf dem Client) -Stateless-Server (zustandslos ohne Application State auf dem Server).

Zusammenfassung

  • REST ist ein Architekturstil für das Web. Zentraler Bestandteil von REST ist ein generisches User-Interface auf Basis von Hypermedia.

Mehr erfahren

Technologie und Innovation bei Q_PERIOR

Haben Sie Interesse an Technologie-Themen und Lust auf eine neue Herausforderung? Dann lernen Sie den Q_PERIOR Bereich Technologie und Innovation kennen!
Mehr erfahren

Mehr zum Thema

WIR SIND FÜR SIE DA!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!

25. März 2019|