REST im Übeblick

REST (Representational State Transfer) ist Voraussetzung für eine Architektur, welche auf Microservice basiert. Man nutzt es, um mit den unterschiedlichsten APIs zu kommunizieren.
Microservices und Cloud halten mehr und mehr Einzug in die Entwicklung aller Arten von Applikationen. Statt monolithisch aufgebauter Clients teilt man die Funktionalität auf viele kleinere Einheiten auf, welche lose miteinander gekoppelt werden. Dieses erhöht die Flexibilität und als Programmierer kann man auf das Know-how von anderen Entwicklern und Serviceanbietern zurückgreifen, welche entsprechende Funktionen zur Verfügung stellen. Einmal programmierte Services können dann in mehreren Anwendungen auf einfachste Art und Weise wiederverwendet werden. Ebenso ist es üblich, dass in den Applikationen zunehmend auf Cloud-Dienste zurückgegriffen wird. Auf diese Weise können auch Apps auf mobilen Geräten oder Web-Applikationen die Power einer ganzen Rechnerlandschaft nutzen. Ein gutes Beispiel ist die Interaktion mit KI-Diensten. Aus den Anwendungen übermitteln wir die Daten über definierte Schnittstellen an einen Server, dort werden sie verarbeitet und man erhält umgehend die gewünschte Antwort. Ein Anwendungssystem, welches REST-Services nutzt, basiert dann auf der in Bild 1 dargestellten Architektur.

Wenn wir davon sprechen, dass ein funktionaler Softwareservice, zum Beispiel bestimmte KI-Algorithmen, das Bereitstellen von Wetterdaten oder die Nutzeridentifikation über einen Social-Media-Kanal angeboten werden, dann gehen wir davon aus, dass dieses über ein API erfolgt. Werden Client und Server über Netzwerke (Internet) miteinander vermittelt, dann basiert ein solches API meist auf der Basis von REST. REST hat sich dafür als Standard etabliert und steht als Abkürzung für REpresentational State Transfer. REST selbst ist dabei allerdings weder Protokoll noch Standard. Schnittstellen (API), welche auf REST setzen, werden im Entwickler-Jargon auch gern als „RESTful“ bezeichnet. Derartige Implementierungen setzen allerdings wiederum auf standardisierte Verfahren, wie HTTP/S, URI, JSON oder XML.

REST basiert auf folgenden Architekturprinzipien [1]:

• Client-Server-Modell: Die Kommunikation erfolgt auf der Basis eines Client-Server-Modells. Das Ziel ist eine flexible und generische Nutzung der Services über Plattformgrenzen hinweg. Services, welche via REST zur Verfügung gestellt werden, können damit von den unterschiedlichsten Clients genutzt werden. Ein Beispiel: Ein Wetterdienst stellt seine Programmschnittstelle via REST zur Nutzung. Über bestimmte Bezahlmodelle können Entwickler von App und Webseiten diesen Service nutzen, d.h. die Wetterdaten für einen bestimmten Ort abrufen.
• Zustandslosigkeit: Die Kommunikation zwischen Client und Server ist stets zustandslos. Was heißt das? Jede Anfrage vom Client an den Server muss vollständig sein. Der Server kann auf keine vorherige Anfrage zurückgreifen. Die Vorteile sind eine hohe Zuverlässigkeit und eine einfache Skalierbarkeit. Als Nachteil ergibt sich eine höhere Netzlast, da jede Anfrage von einem vollständigen Datensatz begleitet werden muss. Ein Beispiel: Bei der Abfrage der Wetterdaten muss beispielsweise der Ort übermittelt werden. Möchte man mit einer zweiten Anfrage noch das Wetter von einem anderen Tag erfragen, ist die Angabe zum Ort nochmals zu übermitteln.
• Caching: Clients können Antworten des Servers speichern. Damit können Netzausfälle überbrückt oder ein zeitweiser Offline-Betrieb ermöglicht werden. Diese zwischengespeicherten Daten können dann bei einer erneuten Anfrage alternativ statt einer neuen Antwort vom Server verwendet werden. Informationen müssen als „cacheable“ oder „non-cacheable“ gekennzeichnet werden. Die Vorteile sind eine erhöhte Geschwindigkeit. Ein Nachteil besteht darin, dass ein Client auf veraltete Daten zurückgreift.
• Einheitliche Schnittstelle: Restkonforme Services (RESTful API) nutzen eine einheitliche Schnittstelle, welche vom bereitgestellten Dienst entkoppelt ist. Damit entsteht die Möglichkeit einer universellen Verwendung. Als Nachteil muss der Dienst die Input- und Output-Daten in ein einheitliches Format bringen. Das verursacht einen Aufwand und kann zu Lasten der Effizienz der Datenverarbeitung gehen. Es ist aber notwendig, wenn man zwischen Nutzung (Client) und Bereitstellung (Server) weitgehend technisch entkoppeln möchte.
• Mehrschichtig (Layered System): Das Gesamtsystem besteht aus einzelnen Schichten. Dabei kennt jede einzelne Komponenten nur die mit ihr verknüpften Komponenten. Dies dient dazu die Systemkomplexität zu senken und die Erweiterbarkeit des Systems zu vereinfachen.
• Code on Demand: Diese Forderung an eine REST-API ist optional. Es ermöglicht Clients, ihre Flexibilität zu verbessern. Zum Beispiel kann ein Client ein JavaScript ausführen, um die Kommunikation mit dem Server zu verschlüsseln. Nicht jede API benötigt diese Flexibilität.
• Wenn Sie diese Ziele und Voraussetzungen von REST lesen, dann stellt sich unmittelbar die Frage nach der Abgrenzung zu SOA. Der Textkasten: „REST vs. SOA“ sorgt für Aufklärung.

Ein REST-API wird i.d.R. per http bzw. https umgesetzt. Die Services werden per URL und den üblichen http-Methoden GET, Post, PUT usw. genutzt, d.h. der Client sendet eine Anfrage (Request) an den Server und erhält eine Antwort (Response). Damit sind wir auch schon beim nächsten Thema, dem Aufbau einer solchen Anfrage.

REST vs. SOA

Auch bei der Serviceorientierten Architektur (SOA) handelt es ich um eine verteilte Systemarchitektur. Das Prinzip von der SOA besteht darin, dass Nutzer (Service Consumer) komplexe Anwendung nahezu aus dem Zusammenfassen bzw. der Kombination von Service-Dienstleistungen realisieren können. Die dahinterstehende Idee ist es, sinnvoll zusammengehörende Anwendungsfunktionalitäten zu einer Einheit zu bündeln und diese als Dienstleistungen (SOA-Services) zur Verfügung zu stellen. Insofern gleichen sich beide Technologieansätze, wobei SOA schon deutlich länger verfügbar ist. Gelegentlich hört man auch die Meinung, dass REST die Nachfolge von SOA antritt. So einfach ist es jedoch nicht. Beide Technologieansätze haben aus heutiger Sicht Ihre Berechtigung. Bei SOA liegt der Fokus auf der Realisierung von komplexen Funktionen, welche durchaus auch geschäftskritische Prozesse abdecken. Da diese Architektur schon relativ lange existiert, haben sich in diesem Bereich Tools, Prozesse und Methodiken, d.h. ein sogenanntes Standardwork etabliert. Dabei entstehen oft große und unhandliche Systeme. SOA ist insgesamt gut geeignet um die Funktionalität von größeren Projekten auf mehrere Services aufzuteilen und diese innerhalb des Anwendungssystems wiederzuverwenden.
RESTful-Architekturen zielen eher darauf ab, Cloud-Services als flexible Funktionen für eine Anwendung über das Internet und über http-Standardmethoden verfügbar zu machen. Zwei Beispiele machen die unterschiedlichen Einsatzbereiche von SOA und REST deutlich, wobei es natürlich Überschneidungen gibt:

• SOA: Auslagerung eines Dokumentenmanagementsystems (DMS) als Service. Dieser Service wird von mehreren Programmen des Anwendungssystems genutzt. Der Service hat eine durchaus hohe Komplexität und deckt einen großen Funktionsumfang ab.
• REST: Nutzung der Authentifizierungsservices eines Social-Media-Anbieters als Login für eine Applikation.

SOA und REST sind jedoch beides Methoden, die Funktionen eines Anwendungssystems auf kleinere Einheiten aufzuteilen.

Die Aufbau eines Requests

Ein Request (Anfrage) besteht aus vier Bestandteilen (Bild 2):

• Endpunkt (endpoint)
• Methode (method)
• Header (header)
• Daten (data).

Sehen wir uns den Aufbau etwas detaillierter an. Der Endpunkt (endpoint) setzt sich aus dem root-endpoint, dem path und möglichen Parametern zusammen. Beispielsweise ist https://api.github.com der root-Endpoint von GitHub und /users/veikkoef/repos der path zu den Repositories der Autoren. Zusammen ergibt dieses https://api.github.com/users/veikkoef/repos. Es können noch Parameter nach dem folgenden Muster folgen: ?query1=value1&query2=value2.
Als nächstes betrachten wir die Methode. Hier geht es um die http-Methoden GET, POST, PUT/ PATCH und DELETE. GET steht für Read-Operationen, also das Abfragen bzw. Lesen von Daten. Da GET-Requests nur lesend auf dem Server zugreifen, können sie beliebig oft abgeschickt werden. GET ist die standardmäßige Methode. POST wird für Create-Operationen, also das Erzeugen eines Datensatzes eingesetzt. Beispielsweise könnte eine Adresse zu einer Adresstabelle hinzugefügt werden. POST ist nicht frei von Seiteneffekten. Es können durch einen POST-Aufruf Felder in einer Datenbank verändert oder Prozesse auf dem Server gestartet werden. PUT/ PATCH verwendet man für Update-Operationen und DELETE für das Löschen von Daten.
Das dritte Element einer Anfrage ist der Header. Der Header dient zur Bereitstellung von Informationen für den Client und den Server. Dieser kann für viele Zwecke verwendet werden, zum Beispiel zur Authentifizierung und Bereitstellung von Informationen über den nachfolgenden Inhalt. Abschließend und als letztes Element einer Anfrage folgen die Daten („Body“), welche man an den Server übermitteln möchte. Der Body-Bereich ist nur relevant für die Operationen POST, PUT, PATCH oder DELETE.

Literatur und Links

[1] https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/

[2] https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

[3] https://idratherbewriting.com/learnapidoc/docapis_understand_curl.html

[4] https://blog.restcase.com/restful-api-authentication-basics/