REST: Ressourcen, Zustandslosigkeit, einheitliche Schnittstelle

REST steht für REpresentational State Transfer und ist kein Protokoll oder Standard, sondern ein Architekturstil für verteilte Systeme. Roy Fielding hat ihn im Jahr 2000 in seiner Dissertation beschrieben. Eine Schnittstelle gilt nur dann als RESTful, wenn sie bestimmte Prinzipien einhält. In der Praxis werden REST-APIs fast immer über HTTP umgesetzt, REST schreibt HTTP aber nicht zwingend vor.

Ressourcen unter URLs: Die zentrale Idee ist die Ressource. Alles, was sich benennen lässt, kann eine Ressource sein, etwa ein Dokument, ein Bild oder ein Kunde. Jede Ressource wird über eine eindeutige Adresse (URI/URL) angesprochen, zum Beispiel /kunden/42. Auf Ressourcen wird mit den standardisierten HTTP-Methoden zugegriffen, üblicherweise GET, POST, PUT und DELETE.

Repräsentationen: Der Zustand einer Ressource zu einem Zeitpunkt wird als Repräsentation übertragen, bestehend aus den Daten und beschreibenden Metadaten. Ressource und Repräsentation sind entkoppelt, derselbe Inhalt kann also in verschiedenen Formaten ausgeliefert werden (JSON, XML, HTML, PDF und andere). JSON ist heute das gängigste Format.

Zustandslosigkeit (stateless): Jede Anfrage des Clients muss alle Informationen enthalten, die der Server zum Verstehen und Bearbeiten benötigt. Der Server speichert zwischen zwei Anfragen keinen Sitzungszustand, der Sitzungszustand liegt vollständig beim Client. Jede Anfrage steht also für sich allein.

Einheitliche Schnittstelle (uniform interface): Dies ist das Kernmerkmal von REST und beruht auf vier Punkten:

• Eindeutige Identifikation von Ressourcen über URIs.
• Manipulation über Repräsentationen: Der Client ändert den Zustand auf dem Server, indem er Repräsentationen sendet.
• Selbstbeschreibende Nachrichten: Jede Nachricht enthält genug Information, um zu wissen, wie sie zu verarbeiten ist (zum Beispiel über den Media-Type).
• Hypermedia als Steuerung des Anwendungszustands (HATEOAS): Der Client folgt den Links, die der Server in den Antworten mitliefert.

Client-Server-Trennung: Oberfläche (Client) und Datenhaltung (Server) sind voneinander getrennt. So können beide Seiten unabhängig weiterentwickelt werden, solange der vereinbarte Vertrag (die Schnittstelle) stabil bleibt. Das verbessert Portierbarkeit und Skalierbarkeit. Ergänzend nennt REST die Prinzipien Cacheable (Antworten kennzeichnen sich als zwischenspeicherbar) und Layered System (Aufbau in Schichten).

Warum Zustandslosigkeit für Skalierung und Sicherheit zählt: Weil der Server keinen Sitzungszustand vorhalten muss, kann jede Anfrage von einem beliebigen Server beantwortet werden. Das erleichtert Lastverteilung und horizontale Skalierung (einfach mehr Server hinzufügen) und macht das System robuster, da kein Server unverzichtbares Wissen über laufende Sitzungen hält. Für die Sicherheit bedeutet es, dass jede Anfrage die nötigen Berechtigungsangaben selbst mitbringt und einzeln geprüft wird, statt sich auf einen serverseitig gespeicherten, angreifbaren Sitzungskontext zu verlassen. Insgesamt fördern diese Prinzipien einfache, leichtgewichtige und schnelle Anwendungen.

GET /api/kunden/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJI...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 42,
  "name": "Erika Musterfrau",
  "status": "aktiv",
  "links": {
    "self": "/api/kunden/42",
    "bestellungen": "/api/kunden/42/bestellungen"
  }
}

Zustandslose GET-Anfrage: Der Client identifiziert die Ressource per URL, sendet seine Berechtigung selbst mit und erhält eine JSON-Repräsentation mit Hypermedia-Links.

Quellen

• REST - Glossary MDN Web Docs
• What is REST? restfulapi.net (REST API Tutorial)