Was ist REST? 🤔

REST steht für Representational State Transfer und ist ein Architekturstil für die Gestaltung verteilter Systeme, insbesondere von Webservices und APIs (Application Programming Interfaces). Es handelt sich dabei nicht um ein spezifisches Protokoll, einen Standard oder eine Technologie, sondern um eine Reihe von architektonischen Prinzipien oder "Constraints" (Einschränkungen). Diese Prinzipien wurden von Roy T. Fielding in seiner Doktorarbeit im Jahr 2000 definiert und leiten sich aus den erfolgreichen Designentscheidungen des World Wide Web (insbesondere des HTTP-Protokolls) ab.

Das Ziel von REST ist es, Systeme zu schaffen, die bestimmte wünschenswerte Eigenschaften aufweisen, wie Skalierbarkeit, Performance, Einfachheit, Modifizierbarkeit, Sichtbarkeit, Portabilität und Zuverlässigkeit. Wenn eine API oder ein Webservice diesen Prinzipien folgt, wird er als "RESTful" bezeichnet. REST ist heute der dominierende Stil für die Gestaltung von Web-APIs.

Die Kernprinzipien (Constraints) von REST

REST definiert sechs grundlegende architektonische Constraints:

1. Client-Server-Architektur: Es gibt eine klare Trennung zwischen dem Client (der die Benutzeroberfläche bereitstellt und Anfragen stellt) und dem Server (der die Daten speichert, die Geschäftslogik ausführt und Anfragen beantwortet). Diese Trennung ermöglicht die unabhängige Entwicklung und Skalierung beider Komponenten.
2. Zustandslosigkeit (Statelessness): Jede Anfrage vom Client an den Server muss alle Informationen enthalten, die zur Bearbeitung notwendig sind. Der Server speichert keinen Kontext oder Zustand (Session State) des Clients zwischen den Anfragen. Jede Anfrage wird isoliert behandelt. Dies verbessert die Skalierbarkeit (Anfragen können an beliebige Serverinstanzen gehen) und Zuverlässigkeit.
3. Zwischenspeicherbarkeit (Cacheability): Antworten des Servers müssen explizit oder implizit angeben, ob sie zwischengespeichert werden dürfen. Caching auf Client-Seite oder durch zwischengeschaltete Systeme (Proxies) kann die Netzwerklast reduzieren und die wahrgenommene Performance erheblich verbessern.
4. Schichtensystem (Layered System): Die Architektur kann aus mehreren hierarchischen Schichten bestehen (z.B. Client, Load Balancer, API Gateway, Anwendungsserver, Datenbank). Ein Client interagiert nur mit der unmittelbar nächsten Schicht und weiß nichts über die dahinterliegenden Schichten. Dies fördert die Skalierbarkeit, Sicherheit und Modularität.
5. Einheitliche Schnittstelle (Uniform Interface): Dies ist ein zentrales Prinzip, das die Interaktion standardisiert und entkoppelt. Es umfasst vier Unterprinzipien:
   • Ressourcenidentifikation: Jede Ressource (z.B. ein Kunde, ein Produkt, eine Bestellung) wird durch eine eindeutige URI (Uniform Resource Identifier) identifiziert.
   • Manipulation von Ressourcen durch Repräsentationen: Clients interagieren mit Ressourcen, indem sie deren Repräsentationen (z.B. im JSON- oder XML-Format) austauschen (senden und empfangen).
   • Selbstbeschreibende Nachrichten: Jede Nachricht (Request und Response) enthält genügend Informationen (z.B. durch Metadaten in HTTP-Headern wie `Content-Type`, `Accept`), um vom Empfänger verstanden zu werden, ohne dass dieser auf externe Dokumentation angewiesen ist.
   • Hypermedia as the Engine of Application State (HATEOAS): Die Antworten des Servers sollten Links (Hypermedia) enthalten, die dem Client mögliche Aktionen oder den Weg zu verwandten Ressourcen aufzeigen, um die Anwendung dynamisch zu steuern. (Dieses Prinzip wird in der Praxis oft nur teilweise umgesetzt).
6. Code-On-Demand (Optional): Der Server kann dem Client optional ausführbaren Code (z.B. JavaScript) senden, um dessen Funktionalität zu erweitern. Dieses Prinzip wird seltener angewendet als die anderen fünf.

RESTful APIs über HTTP

In der Praxis werden die REST-Prinzipien am häufigsten zur Gestaltung von Web-APIs unter Nutzung des HTTP-Protokolls implementiert. Solche APIs werden als "RESTful" bezeichnet und folgen typischerweise diesen Konventionen:

• Ressourcenorientierung: Daten werden als Ressourcen modelliert und über eindeutige URIs angesprochen (z.B. /api/users für eine Liste von Nutzern, /api/users/123 für einen spezifischen Nutzer).
• Nutzung von Standard-HTTP-Methoden: Die Aktionen auf Ressourcen werden durch die Standard-HTTP-Verben ausgedrückt:
  • GET: Ressource(n) abrufen (lesend, sicher, idempotent).
  • POST: Neue Ressource erstellen (nicht idempotent).
  • PUT: Bestehende Ressource vollständig ersetzen oder erstellen, falls sie nicht existiert (idempotent).
  • DELETE: Ressource löschen (idempotent).
  • PATCH: Bestehende Ressource teilweise aktualisieren (nicht notwendigerweise idempotent).
• Verwendung von Repräsentationsformaten: Daten werden üblicherweise in Formaten wie JSON (JavaScript Object Notation - heute am weitesten verbreitet) oder XML ausgetauscht. Der gewünschte bzw. gelieferte Medientyp wird über die HTTP-Header `Accept` und `Content-Type` ausgehandelt.
• Nutzung von HTTP-Statuscodes: Standardisierte HTTP-Statuscodes werden verwendet, um das Ergebnis der Anfrage zu signalisieren (z.B. 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error).

Vorteile und Einordnung

Eine gut gestaltete RESTful Architektur bietet zahlreiche Vorteile:

• Einfachheit und Vertrautheit: Baut auf den weit verbreiteten und gut verstandenen Standards des Webs (HTTP, URI, JSON) auf.
• Skalierbarkeit: Die Prinzipien der Zustandslosigkeit und Cacheability ermöglichen eine gute horizontale Skalierbarkeit von Servern.
• Performance: Caching kann die Latenz reduzieren und die Effizienz steigern.
• Flexibilität und Entkopplung: Client und Server können unabhängig voneinander entwickelt und weiterentwickelt werden, solange die Schnittstelle stabil bleibt.
• Portabilität und Interoperabilität: RESTful APIs können von einer Vielzahl unterschiedlicher Clients (Webbrowser, mobile Apps, andere Server) genutzt werden.
• Sichtbarkeit und Zuverlässigkeit: Zustandlose Interaktionen sind einfacher zu überwachen, zu debuggen und wiederherzustellen.

REST ist heute der dominierende Architekturstil für Web-APIs und die Kommunikation zwischen Microservices. Alternativen sind ältere Ansätze wie SOAP (stärker protokollbasiert, oft mit WSDL und XML verbunden) oder neuere Ansätze wie GraphQL (eine Abfragesprache für APIs, die Clients mehr Kontrolle über die angeforderten Daten gibt).