Die Prinzipien des RESTful-API-Designs verstehen

RESTful-APIs ermöglichen es Client-Anwendungen, mithilfe eines standardisierten Satzes von Regeln und Protokollen auf Ressourcen (Daten) zuzugreifen, die auf einem Remote-Server gehostet werden, und diese zu bearbeiten. REST steht für „Representational State Transfer“ – eine Reihe von Architekturprinzipien, die festlegen, wie diese Schnittstellen entworfen und implementiert werden. Zu den wichtigsten Prinzipien des RESTful-Designs gehören die Verwendung von HTTP-Methoden – wie „POST“, „GET“, „PATCH“ und „DELETE“ – zur Durchführung von CRUD-Operationen (Create, Read, Update, Delete), die Identifizierung von Ressourcen durch eindeutige URLs sowie die Übertragung von Daten in einem schlanken Format wie JSON. RESTful-APIs bieten eine flexible und standardisierte Möglichkeit für Systeme, über das Internet miteinander zu kommunizieren, was sie zu einem grundlegenden Baustein moderner Web- und Mobilanwendungen macht.

Dieser Artikel behandelt die Grundlagen des Designs von RESTful-APIs. Am Ende werden wir die wichtigsten REST-Prinzipien untersuchen, sie mit anderen Paradigmen vergleichen und Best Practices für das Design von RESTful-APIs besprechen.

Prinzipien des API-Designs

Bevor wir ins Detail gehen, wollen wir kurz einen Blick darauf werfen, wie sich REST im Vergleich zu anderen gängigen Methoden des API-Designs darstellt.

REST

Wie bereits erwähnt, sind REST-APIs eher um Ressourcen (Substantive) als um Aktionen herum strukturiert und nutzen Standard-HTTP-Methoden (GET, POST, PUT, DELETE), um diese Ressourcen zu bearbeiten. RESTful-APIs basieren auf mehreren Schlüsselprinzipien für konsistente und skalierbare Webdienste:

• Zustandslose Kommunikation. REST-API-Anfragen enthalten alle notwendigen Informationen, wobei zwischen den Anfragen kein Client-Kontext auf dem Server gespeichert wird.
• Einheitliche Schnittstelle. Dieses Prinzip gewährleistet eine konsistente Identifizierung und Bearbeitung von Ressourcen durch selbstbeschreibende Nachrichten unter Verwendung von Standard-HTTP-Headern und Statuscodes. Es umfasst außerdem HATEOAS (Hypermedia as the Engine of Application State), wodurch Clients die API-Fähigkeiten dynamisch ermitteln können.

GraphQL

GraphQL wurde von Facebook entwickelt und ist eine Abfragesprache sowie eine Laufzeitumgebung, die eine effizientere und flexiblere Datenabfrage ermöglicht als herkömmliche REST-Endpunkte. Die zentralen Designprinzipien lauten wie folgt:

• Flexibilität bei Abfragen. Dadurch können Clients angeben, welche Daten sie in der Antwort benötigen. Das bedeutet, dass mehrere Ressourcen in einer einzigen Abfrage angefordert werden können, während ein Über- oder Unterabruf von Daten vermieden wird.
• Ein-Endpunkt-Architektur. Sie leitet alle Anfragen über einen einzigen Endpunkt weiter und unterscheidet dabei zwischen Abfragen und Mutationen. Ein Schema definiert alle möglichen Operationen und Typen innerhalb der Architektur.
• Starkes Typsystem. Dies dient als Vertrag zwischen Client und Server, bietet integrierte Typvalidierung und Dokumentation und ermöglicht gleichzeitig leistungsstarke Entwicklertools und Typüberprüfung.

gRPC

gRPC wurde von Google entwickelt und ist ein auf HTTP/2 basierendes RPC-Framework (Remote Procedure Call). Es basiert auf den folgenden Kernprinzipien:

• „Contract-first“-Entwicklung. Nutzt Protocol Buffers (protobuf) als strenge Schnittstellendefinitionssprache (IDL) und ermöglicht so die automatische Codegenerierung sowohl für Client- als auch für Server-Implementierungen.
• Streaming-Unterstützung. Bietet Funktionen für unäres, server-, client- und bidirektionales Streaming, was es effizient für Echtzeitkommunikation und große Datenübertragungen macht, insbesondere bei der Kommunikation zwischen Microservices.
• Binäres Protokoll. Es nutzt HTTP/2 als Transportschicht, was eine hocheffiziente binäre Serialisierung ermöglicht. Das führt zu geringerer Latenz und besserer performance im Vergleich zu textbasierten Protokollen.

Überblick über die Prinzipien des API-Designs

Hier ist eine Tabelle, die einige der Unterschiede zwischen diesen Entwürfen zusammenfasst:

Überblick über die RESTful-API-Architektur

Ein System, das eine RESTful-API nutzt, umfasst in der Regel drei Schlüsselkomponenten: den Client, den Server und die Datenbank. Dazu kommen weitere Elemente wie ein Load Balancer, Caching und ein Authentifizierungsdienst.

Client

Der Client ist jede Anwendung oder jedes Gerät, das die API nutzt. Das kann ein Webbrowser, eine mobile App oder ein anderer Server in einer Microservices-Architektur sein. Clients senden Anfragen mithilfe von HTTP-Methoden (z. B. GET, POST, PUT, DELETE) an den Server, um CRUD-Operationen an Ressourcen durchzuführen – zum Beispiel eine mobile App, die Benutzerdaten abruft, indem sie eine GET-Anfrage an https://api.example.com/users sendet.

API-Server

Der Server hostet die API und ist dafür zuständig, eingehende Client-Anfragen zu verarbeiten, mit der Datenbank oder anderen Diensten zu interagieren und Antworten zurückzugeben. Der Server interpretiert die HTTP-Anfragen, führt die erforderlichen Vorgänge aus (wie das Erstellen, Abrufen, Aktualisieren oder Löschen von Ressourcen) und gibt die entsprechenden HTTP-Statuscodes und Daten zurück.

Middleware bildet optionale Schichten, die in die Serverarchitektur integriert werden können, um zusätzliche Funktionen zu übernehmen. Dazu können Authentifizierung, Protokollierung, Datenvalidierung, Fehlerbehandlung sowie die Umwandlung von Anfragen und Antworten gehören. Middleware verarbeitet Anfragen, bevor sie die Kernlogik des Servers erreichen, und kann auch Antworten ändern, bevor diese an den Client zurückgesendet werden.

Datenbank

Die Datenbank speichert die Anwendungsdaten. Dabei kann es sich um eine relationale Datenbank (wie PostgreSQL oder MySQL), eine NoSQL-Datenbank (wie MongoDB) oder jede andere Form der Datenspeicherung handeln. Der Server nutzt die Datenbank, um Daten wie Benutzerinformationen, Produktdetails oder Transaktionsverläufe dauerhaft zu speichern und abzurufen.

Innerhalb der Datenbank speichert eine Caching-Schicht Kopien häufig abgefragter Daten, um wiederholte Zugriffe auf die Datenbank zu vermeiden. Das hilft, die Latenz zu verringern, indem Daten aus dem Cache bereitgestellt werden, anstatt jedes Mal die Datenbank abzufragen. Dies wird oft mithilfe von In-Memory-Datenbanken wie Redis oder Memcached erreicht.

Lastverteiler

Ein Load Balancer kann genutzt werden, um eingehende Client-Anfragen auf mehrere Serverinstanzen zu verteilen. Das trägt dazu bei, hohe Verfügbarkeit und Skalierbarkeit sicherzustellen und verhindert, dass ein einzelner Server zum Engpass wird. Er verteilt den Datenverkehr gleichmäßig auf mehrere Serverinstanzen, um die Antwortzeiten zu verbessern, sorgt für Fehlertoleranz, indem er Anfragen umleitet, wenn ein Server nicht mehr reagiert, und kann zudem die SSL-Terminierung übernehmen, um die Server von der Ver- und Entschlüsselung zu entlasten.

Auf modernen Plattformen wie Upsun Cloud ist diese Funktionalität oft in eine Edge-Layer-Architektur integriert, die vor den Anwendungscontainern angesiedelt ist und das Routing von Anfragen, die TLS-Terminierung, WAF sowie DDoS-Abwehr übernimmt. Der Lastausgleich über Anwendungsinstanzen hinweg erfolgt typischerweise über einen umgebungsspezifischen Reverse-Proxy, der diesem Edge nachgeschaltet ist.

Wichtige Merkmale von REST-APIs

REST-APIs basieren auf mehreren Kernprinzipien, die ihre Architektur und ihr Verhalten definieren.

Client-Server-Architektur

In einer RESTful-API-Architektur arbeiten Client und Server unabhängig voneinander. Der Client (z. B. ein Webbrowser oder eine mobile App) ist für die Benutzeroberfläche zuständig und initiiert Anfragen, während der Server die Datenverarbeitung und die Antworten übernimmt. Diese Trennung der Aufgabenbereiche sorgt langfristig für Wartbarkeit und Flexibilität.

So kann beispielsweise eine mobile App über die API mit dem REST-Server interagieren, ohne die Implementierungsdetails verstehen zu müssen. Wenn die Backend-API Code für die Benutzeroberfläche enthält, entsteht eine enge Kopplung zwischen Client und Server, was zu Abhängigkeitsproblemen führt und Updates erschwert.

Zustandslose Kommunikation

Wie bereits erwähnt, enthält in einer zustandslosen Architektur jede Anfrage vom Client an den Server alle Informationen, die zur Bearbeitung der Anfrage benötigt werden. Der Server speichert keine client-spezifischen Sitzungsdaten. Das erleichtert die horizontale Skalierung der API-Server-Ebene. Da jede Anfrage in sich geschlossen ist, können Server sie unabhängig voneinander bearbeiten, was den Lastausgleich vereinfacht. Es bedeutet auch, dass Server keinen Sitzungsstatus speichern müssen, was den Speicherbedarf reduziert.

Beispielsweise muss ein API-Aufruf zur Anmeldung in jeder Anfrage die Anmeldedaten des Nutzers enthalten, anstatt sich auf eine auf dem Server gespeicherte Sitzungs-ID zu verlassen. Dadurch kann jeder Server in einem Cluster die Anfrage bearbeiten, ohne vorherigen Kontext zu benötigen. Wenn sich ein Server auf Sitzungsdaten stützt, die zwischen den Anfragen gespeichert werden, verkompliziert das die Skalierung und erschwert es Lastenausgleichssystemen, Anfragen gleichmäßig zu verteilen.

Zwischenspeicherbare Antworten

Die Antworten von RESTful-APIs können zwischengespeichert werden, sodass Clients oder Zwischeninstanzen die Antworten für eine bestimmte Zeit speichern können. Das minimiert die Notwendigkeit wiederholter Anfragen für dieselben Daten. Zwischengespeicherte Daten können schneller bereitgestellt werden, als wenn jedes Mal der Server abgefragt werden müsste. Außerdem verringert es die Latenz und die Serverauslastung, was die Benutzererfahrung und die Skalierbarkeit verbessert.

Eine API-Antwort kann Caching-Header wie „Cache-Control“ und „Expires“ enthalten, wodurch der Client die Daten vorübergehend speichern und unnötige Aufrufe an den Server vermeiden kann. Beispielsweise könnte eine zwischenspeicherbare Wetter-API-Antwort die Notwendigkeit häufiger Aktualisierungen verringern, wenn die Daten eine Stunde lang unverändert bleiben. Fehlen in den Antworten Caching-Header, fordern Clients dieselben Daten wiederholt an, was den Server unnötig belastet und die Antwortzeit für den Endnutzer verlangsamt.

Schichtbasiertes System

Ein mehrschichtiges System ermöglicht es APIs, über mehrere Schichten hinweg zu arbeiten – wie beispielsweise Vermittler, Load Balancer und Gateways –, ohne dass der Client diese Schichten wahrnimmt. Dieser Ansatz bietet zusätzliche Sicherheit und Skalierbarkeit. So können Load Balancer beispielsweise dabei helfen, den Datenverkehr zu verteilen, ohne dass der Client wissen muss, wie der Lastausgleich erfolgt. Diese Modularität erleichtert es, Teile des Systems zu skalieren oder abzusichern, ohne die gesamte API neu gestalten zu müssen.

Wenn ein Client einen Aufruf an eine API sendet, kann dieser automatisch über einen Lastverteiler und eine Firewall geleitet werden, was für optimierte performance und Sicherheit sorgt, ohne den Client-Code zu ändern. Muss ein Client direkt mit mehreren Backend-Servern interagieren oder verstehen, wie Anfragen verteilt werden, führt das zu Komplexität und durchbricht die schichtweise Abstraktion.

Einheitliche Schnittstelle

Ein weiteres Kernprinzip von REST-APIs ist das Prinzip der einheitlichen Schnittstelle („Uniform Interface“), also eine Reihe von Standardregeln für die Interaktion mit der API. Dazu gehören die konsistente Verwendung von HTTP-Methoden (GET, POST, PUT, DELETE), Standard-URL-Muster und vorhersehbare Antwortformate. Eine einheitliche Schnittstelle verbessert die Benutzerfreundlichkeit der API und macht es Entwicklern leichter, vorherzusagen, wie die API auf Anfragen reagieren wird. Diese Konsistenz verringert den Lernaufwand und die Fehlerwahrscheinlichkeit.

Eine RESTful-API verwendet HTTP-Methoden einheitlich über alle Ressourcen hinweg (z. B. ruft GET /users Benutzer ab, POST /users legt einen Benutzer an), was Einheitlichkeit und Vorhersehbarkeit gewährleistet. Eine API, die nicht standardisierte Methoden verwendet oder HTTP-Methoden vermischt (z. B. die Verwendung von GET zum Anlegen einer Ressource), kann Entwickler verwirren und die zuverlässige Nutzung der API erschweren.

Code on Demand

„Code on Demand“ ist eine optionale architektonische Vorgabe von REST, die es Servern ermöglicht, die Funktionalität von Clients zu erweitern, indem sie zur Laufzeit ausführbaren Code wie JavaScript an Clients übermitteln – zum Beispiel zum Laden dynamischer Widgets oder zum Aktualisieren von UI-Komponenten ohne Seitenaktualisierung.

Dadurch kann der Client die Funktionalität dynamisch erweitern, ohne sein Programmieren aktualisieren zu müssen. Das bietet Flexibilität und kann die Funktionalität verbessern, indem Clients Code direkt vom Server ausführen können – besonders in dynamischen Webanwendungen.

Fazit

Dieser Artikel hat sich mit den Gestaltungsprinzipien für RESTful-APIs und den wesentlichen Komponenten befasst, die eine API RESTful machen. Er begann mit einem Überblick über Alternativen beim API-Design und einer Topologie typischer RESTful-Systemarchitekturen sowie einer eingehenden Betrachtung der Schlüsselkomponenten von RESTful-APIs. Die Einhaltung der Gestaltungsprinzipien für RESTful-APIs kann die Codequalität verbessern und sicherstellen, dass deine APIs den Nutzern effektiv und effizient dienen, was deine Anwendung langfristig erfolgreicher macht.

Upsun Cloud gibt modernen Entwicklungsteams die Freiheit, einfach zu experimentieren, schnell zu iterieren und mühelos in jeder Dimension zu skalieren. Es handelt sich um eine selbstverwaltete, vollständig verwaltete, sichere und entwicklerorientierte cloud-basierte Anwendungsplattform mit integrierter Beobachtbarkeit, Multicloud-Edge-Caching, zuverlässiger Bereitstellung und der Freiheit, deinen Stack und Cloud-Anbieter selbst zu wählen. Mit Upsun Cloud kannst du RESTful-API-Anwendungen mit den Programmiersprachen und Frameworks deiner Wahl erstellen und ausführen. Du hast die vollständige Kontrolle darüber, wie du Anwendungen skalieren möchtest (horizontal oder vertikal), während Upsun Cloud die aufwendigen Aufgaben übernimmt, einschließlich der Ressourcenzuweisung und der Bewältigung von Traffic-Spitzen.