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 und diese zu bearbeiten, die auf einem Remote-Server gehostet werden. REST steht für „Representational State Transfer“ und bezeichnet 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 über eindeutige URLs und 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 vorstellen.

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 API-Entwurfsmethoden darstellt.

RESTful

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 auch HATEOAS (Hypermedia as the Engine of Application State), wodurch Clients API-Fähigkeiten dynamisch erkennen können.

GraphQL

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

• Flexibilität bei Abfragen. Dies ermöglicht es Clients, anzugeben, 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.
• Single-Endpoint-Architektur. Sie leitet alle Anfragen über einen einzigen Endpunkt und unterscheidet dabei zwischen Abfrage- und Mutationstypen. 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 Typprüfung.

gRPC

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

• Contract-First-Entwicklung. Nutzt Protocol Buffers (protobuf) als strenge Schnittstellendefinitionssprache (IDL) und ermöglicht so die automatische Codegenerierung für Client- und 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. Dies führt zu geringerer Latenz und besserer performance im Vergleich zu textbasierten Protokollen.

Übersicht über die API-Designprinzipien

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 an den Server mithilfe von HTTP-Methoden (z. B. GET, POST, PUT, DELETE), 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 Operationen durch (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 und die Umwandlung von Anfragen und Antworten gehören. Middleware verarbeitet Anfragen, bevor sie die Kernlogik des Servers erreichen, und kann auch Antworten ändern, bevor sie 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 eine beliebige andere Form der Datenspeicherung handeln. Der Server nutzt die Datenbank, um Daten wie Benutzerinformationen, Produktdetails oder Transaktionshistorien dauerhaft zu speichern und abzurufen.

Innerhalb der Datenbank speichert eine Caching-Schicht Kopien häufig angeforderter Daten, um wiederholte Zugriffe auf die Datenbank zu vermeiden. Dies 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.

Lastenausgleich

Ein Load Balancer kann verwendet werden, um eingehende Client-Anfragen auf mehrere Serverinstanzen zu verteilen. Dies trägt dazu bei, hohe Verfügbarkeit und Skalierbarkeit sicherzustellen und verhindert, dass ein einzelner Server zum Engpass wird. Er verteilt den Datenverkehr auf mehrere Serverinstanzen, um die Antwortzeiten zu verbessern, bietet Fehlertoleranz durch Umleitung von Anfragen, falls ein Server nicht mehr reagiert, und kann auch die SSL-Terminierung übernehmen, um die Server von der Ver- und Entschlüsselung zu entlasten.

Auf modernen Plattformen wie Upsun ist diese Funktionalität oft in eine Edge-Layer-Architektur integriert, die vor den Anwendungscontainern sitzt und das Routing von Anfragen, die TLS-Terminierung, WAF und 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 Aufgabentrennung sorgt für langfristige Wartbarkeit und Flexibilität.

Beispielsweise kann eine mobile App über ihre 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 clientspezifischen Sitzungsdaten. Dies 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 Benutzers 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 zwischen Anfragen gespeicherte Sitzungsdaten verlässt, erschwert dies die Skalierung und macht es für Lastverteiler schwierig, Anfragen gleichmäßig zu verteilen.

Zwischenspeicherbare Antworten

Die Antworten von RESTful-APIs können zwischengespeichert werden, sodass Clients oder Zwischenstellen die Antworten für eine bestimmte Zeit speichern können. Dies 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 werden Latenz und Serverauslastung reduziert, 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 wiederholt dieselben Daten 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 Vermittler, Load Balancer und Gateways –, ohne dass der Client diese Schichten wahrnimmt. Dieser Ansatz bietet zusätzliche Sicherheit und Skalierbarkeit. Zum Beispiel können Load Balancer dabei helfen, den Datenverkehr zu verteilen, ohne dass der Client wissen muss, wie die Last verteilt wird. 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 Load Balancer und eine Firewall geleitet werden, was für optimierte performance und Sicherheit sorgt, ohne den Client-Code zu ändern. Wenn ein Client direkt mit mehreren Backend-Servern interagieren oder verstehen muss, wie Anfragen verteilt werden, führt dies zu Komplexität und durchbricht die mehrschichtige Abstraktion.

Einheitliche Schnittstelle

Ein weiteres Kernprinzip von REST-APIs ist die Vorgabe der einheitlichen Schnittstelle, 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 die Einarbeitungszeit und die Fehlerwahrscheinlichkeit.

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

Code on Demand

Code on Demand ist eine optionale REST-Architektur-Richtlinie, die es Servern ermöglicht, die Client-Funktionalität zu erweitern, indem sie ausführbaren Code wie JavaScript zur Laufzeit an Clients übermitteln, z. B. 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. Dies bietet Flexibilität und kann die Funktionalität verbessern, indem Clients Code direkt vom Server ausführen können, insbesondere in dynamischen Webanwendungen.

Fazit

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

Upsun gibt modernen Entwicklungsteams die Freiheit, einfach zu experimentieren, schnell zu iterieren und mühelos in jeder Dimension zu skalieren. Es ist eine selbstverwaltete, vollständig verwaltete, sichere und entwicklerorientierte cloud-basierte Anwendungsplattform mit integrierter Observability, Multicloud-Edge-Caching, zuverlässiger Bereitstellung und der Freiheit, deinen Stack und Cloud-Anbieter selbst zu wählen. Mit Upsun 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 die aufwendigen Aufgaben übernimmt, einschließlich der Ressourcenzuweisung und der Bewältigung von Traffic-Spitzen.