© best_vector/Shutterstock.com
Teil 1: Einführung, technische Hintergründe, erste Experimente

Gib uns (den) REST


REST ist Voraussetzung für eine Architektur, die auf Microservices basiert. Man nutzt es, um mit den unterschiedlichsten APIs zu kommunizieren. In dieser zweiteiligen Artikelserie erfahren Sie alles Wichtige rund um die Arbeit mit RESTful APIs und können dadurch den Grundstein für moderne, funktional verteilte Webapplikationen und Apps legen.

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, die lose miteinander gekoppelt werden. Das erhöht die Flexibilität, und als Programmierer kann man auf das Know-how anderer Entwickler und Service-Anbieter zurückgreifen, die 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 Webapplikationen 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, das REST Services nutzt, basiert dann auf der in Abbildung 1 dargestellten Architektur.

krypczyk_bochkor_rest_1.tif_fmt1.jpgAbb. 1: Anwendungssystem mit REST-API-Architektur

Wie werden diese Dienste bereitgestellt? Natürlich in Form eines Application Programming Interface (API). Die Kommunikation basiert auf festgelegten Standards, meist auf der Basis von REST. Egal wohin Sie als Entwickler blicken, überall begegnen Ihnen REST-basierte Interfaces. Es ist also mehr als notwendig, die dahinterstehende Philosophie zu verstehen, und das am besten „restlos“.

In zwei Artikeln arbeiten wir das Thema systematisch auf. Damit schaffen Sie die Voraussetzungen, um bestehende Services via REST zu nutzen bzw. ein eigenes API bereitzustellen und für andere Anwendungssysteme mittels REST nutzbar zu machen.

Was ist REST?

Wenn wir davon sprechen, dass ein funktionaler Software-Service – zum Beispiel bestimmte KI-Algorithmen, das Bereitstellen von Wetterdaten oder die Nutzeridentifikation über einen Social-Media-Kanal – angeboten wird, gehen wir davon aus, dass das über ein API erfolgt. Werden Client und Server über Netzwerke (Internet) miteinander verbunden, 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. Es ist dabei allerdings weder Protokoll noch Standard. Schnittstellen (APIs), die auf REST setzen, werden im Entwicklerjargon 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, die 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 zur Verfügung. Über bestimmte Bezahlmodelle können Entwickler von Apps und Websites 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 es kann ein zeitweiser Offlinebetrieb 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. Ein Vorteil ist eine erhöhte Geschwindigkeit. Ein Nachteil besteht darin, dass ein Client auf veraltete Daten zurückgreift.

  • Einheitliche Schnittstelle: REST-konforme Services (RESTful APIs) nutzen eine einheitliche Schnittstelle, die vom bereitgestellten Dienst entkoppelt ist. Damit entsteht die Möglichkeit einer universellen Verwendung. Als Nachteil muss der Dienst die Input- und Outputdaten in ein einheitliches Format bringen. Das verursacht Aufwand und kann zu Lasten der Effizienz der Datenverarbeitung gehen, ist aber notwendig, wenn man Nutzung (Client) und Bereitstellung (Server) weitgehend technisch entkoppeln möchte.

  • Mehrschichtig (Layered System): Das Gesamtsystem besteht aus einzelnen Schichten. Dabei kennt jede einzelne Komponente nur die mit ihr verknüpften Komponenten. Das 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 jedes API benötigt diese Flexibilität.

Bei der Betrachtung dieser Ziele und Voraussetzungen von REST 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 Serv...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang