Geschrieben von

REST API

WebDev

Was ist eine REST API?

Nehmen wir die 2 Begriffe auseinander: REST und API. Letzteres steht für “Application Programming Interface”. Dabei handelt es sich um eine Schnittstelle, über die zwei verschiedene Systeme miteinander kommunizieren können. Wie zwischen diesen Systemen kommuniziert wird, regelt REST.

REST steht für “REpresentational State Transfer” und definiert Regeln und Strukturen wie Systeme über eine API kommunizieren. REST kann als ein Paradigma gesehen werden. Es stellt eine Abstraktion der gesamten Struktur und des Verhaltens des World Wide Web dar. Da REST auf Basis bestehender Strukturen des Internets entwickelt wurde, ist die meiste Infrastruktur im Web schon vorhanden.

Architekturprinzipien von REST

  • Client-Server: Bei REST gelten die Anforderungen des Client-Server-Modells. Der Client fragt beim Server Ressourcen an und der Server liefert die Antwort zurück. Beide Systeme müssen unabhängig voneinander sein und sich unabhängig voneinander entwickeln können.
  • Zustandslosigkeit (Stateless): Die Kommunikation zwischen Client und Server erfolgt zustandslos. Das bedeutet, dass zwischen 2 Nachrichten bzw. Anfragen keine Informationen hinterlassen werden. Zwischen 2 Anfragen besteht also kein Kontext.
  • Caching: Es soll HTTP-Caching genutzt werden, um die Kommunikationsgeschwindigkeit zu verbessern.
  • Einheitliche Schnittstelle: Ziel von REST ist es eine einheitliche Schnittstelle zu liefern. Dazu muss jede Ressource über eine URL eindeutig adressierbar sein. Diese Ressource kann aber auch verschiedene Formate oder Sprachen bereitstellen (HTML, JSON, etc.). Zudem müssen die Nachrichten von REST selbstbeschreibend sein. Hier kommen die standardisierten HTTP-Methoden zum Einsatz. Abschließend gilt hier noch das Prinzip des HATEOAS. HATEOAS steht für “Hypermedia as the Engine of Application State”. Dabei navigiert der Client nur über URLs (z.B. über “href” oder “src” Angaben).
  • Mehrschichtige Systeme (Layered System): REST setzt auf mehrschichtige Systeme, die voneinander abgegrenzt sind.
  • Code on Demand: Hierbei handelt es sich um das Prinzip, dass dem Client auch Code zur Verfügung gestellt werden kann, den dieser lokal bei sich ausführt. JavaScript gehört als klassisches Beispiel dazu.

Funktionsweise und Umsetzung

REST sieht vor, dass ein zustandsloses Client-Server-Protokoll verwendet wird. Dazu kann HTTP oder HTTPS zum Einsatz kommen. Da über HTTP zugegriffen wird, kann nun die entsprechende HTTP-Methode gewählt werden:

HTTP-MethodeBeschreibung
GETHier werden Daten vom Server angefordert. Der Server antwortet entsprechend zurück.
POSTBei POST werden Daten dem Server übermittelt, sprich der Client fügt dem Server eine Ressource hinzu.
PUTHier fragt der Client nach einer Änderung an einer bestehenden Ressource auf dem Server an.
PATCHPATCH funktioniert ähnlich wie PUT, es wird jedoch nur ein Teil der Daten geändert.
DELETEHier lässt der Client eine bestehende Ressource auf dem Server löschen.
HEADFordert von der Ressource Metadaten an.
OPTIONSHier wird geprüft, welche HTTP-Methoden für den Zugriff auf die Ressource zur Verfügung stehen.
CONNECTCONNECT leitet eine Anfrage durch den TCP-Tunnel.
TRACEHier wird die Anfrage so zurückgegeben, wie sie der Server erhält.