gRPC vs. REST

Im großen Atlas des Internets sind Programmierschnittstellen (APIs) die Straßen, die Orte, Strände und andere Ziele miteinander verbinden. APIs ermöglichen es Softwareanwendungen, miteinander zu kommunizieren, um Daten, Funktionen und Funktionalitäten auszutauschen. Ein Imperva-Bericht aus dem Jahr 2023 ergab, dass etwa 71 % des Internetverkehrs aus API-Aufrufen bestand, was zeigt, wie wichtig diese Technologie für das Funktionieren moderner Anwendungen und Unternehmen ist.

Es ist kein Wunder, dass das Wissen, wie man eine API erstellt, für die meisten Entwickler eine grundlegende Fähigkeit ist. Doch wie es sich für eine so wichtige Infrastruktur gehört, gibt es zahlreiche Varianten.

Um unsere Metapher weiterzuführen: Eine 12-spurige Autobahn ist nicht „besser“ als eine einspurige Landstraße; eine solche Autobahn würde das Gefüge eines Stadtviertels zerstören und die Landstraße wäre in einem Gebiet mit hohem Verkehrsaufkommen eine Katastrophe. Bei den verschiedenen Architekturstilen zur Erstellung von APIs, wie REST und gRPC, verhält es sich genauso: Jeder hat Stärken und Schwächen, und das Verständnis dieser Stärken und Schwächen ist für die Erstellung einer intakten Infrastruktur von entscheidender Bedeutung.

Representational State Transfer oder REST besteht aus einer Reihe von Designprinzipien (oder Architekturbeschränkungen): einheitliche Schnittstelle, Client-Server-Entkopplung, Zustandslosigkeit, Cachefähigkeit, geschichtete Systemarchitektur und Code on Demand (optional). APIs, die nach diesen Prinzipien erstellt werden, werden REST-APIs oder RESTful-APIs genannt.

REST-APIs können verschiedene Programmiersprachen und Datenformate verwenden, sofern diese den REST-Prinzipien entsprechen. Dies ist die gebräuchlichste Methode zum Erstellen einer API.

REST-APIs verwenden HTTP-Anfragen (auch HTTP-Methoden genannt) wie GET, POST, PUT und DELETE, um Standard-Datenbankfunktionen auszuführen. Diese Vorgänge werden zum Erstellen, Lesen, Aktualisieren und Löschen von Ressourcendatensätzen verwendet und oft als „CRUD“ bezeichnet. Serverseitige Ressourcen werden durch URLs, die als Endgeräte bezeichnet werden, identifiziert.

Eine REST-API würde zum Beispiel eine GET-Anfrage verwenden, um einen Datensatz abzurufen. Eine POST-Anfrage erstellt einen neuen Datensatz. Eine PUT-Anfrage aktualisiert einen Datensatz und eine DELETE-Anfrage löscht einen Datensatz. Alle HTTP-Methoden können in API-Aufrufen verwendet werden. Eine gut gestaltete REST-API ist wie eine Website, die in einem Webbrowser mit integrierter HTTP-Funktionalität ausgeführt wird.

Ressourceninformationen können einem Client in vielen Messaging-Formaten geliefert werden, einschließlich JavaScript Object Notation (JSON), HTML, XLT, Python, PHP oder einfachem Text. JSON ist beliebt, weil es sowohl für Menschen als auch für Maschinen lesbar und programmiersprachenunabhängig ist.

Mehr über REST vs. GraphQL

Browser-Unterstützung: Da REST-APIs HTTP/1.1 und Standard-HTTP-Methoden sowie Formate wie XML und JSON verwenden, sind sie mit Browsern kompatibel. 

Benutzerfreundlichkeit: Aufgrund seiner Einfachheit und Beliebtheit gilt REST weithin als leichter verständlich, insbesondere für Anfänger. Tools, Tutorials und Anleitungen finden sich in Hülle und Fülle auf GitHub und anderswo.

Flexibilität: REST-APIs gelten als lose Kopplung zwischen Client und Server. Diese Flexibilität ermöglicht einfachere und schnellere Änderungen: Eine Änderung kann auf einer Seite vorgenommen werden, ohne dass die andere Seite geändert werden muss.

Robustes Ökosystem: REST-APIs verfügen über eine beträchtliche Anzahl von Tools sowie umfassenden Support und Dokumentation. Die OpenAPI-Spezifikation oder OAS bietet beispielsweise eine branchenübliche Definition der Parameter und Funktionen einer REST-API. Die neueste Version von OAS, OAS 3.1, bietet volle Kompatibilität mit dem JSON-Schema, eine standardisierte Identifizierung, die den SPDX-Identifikator verwendet und mehr.

Abhängigkeit von HTTP/1.1: Die Verwendung von HTTP/1.1 durch REST bietet zwar universelle Browser-Unterstützung und einige Anpassungen in Headern, nimmt REST-APIs aber auch einige der Vorteile des neueren HTTP/2. Zu diesen fehlenden Vorteilen gehört das bidirektionale Streaming. REST unterstützt nur unäres Streaming, bei dem auf eine Anfrage eine Antwort folgt.

Langsamkeit und geringere Effizienz: Wie bei HTTP/1.1 bringt die Abhängigkeit von REST von Formaten wie XML und JSON sowohl Nachteile als auch Vorteile mit sich. Diese Formate sind für den Menschen lesbar, was gut ist, aber sie sind auch vergleichsweise große Dateien und werden daher langsamer übertragen.

Notwendigkeit zusätzlicher Tools: Das Ökosystem von REST mag robust sein, muss es aber auch sein, da einige Funktionen nicht in die Architektur integriert sind. Zum Beispiel ist Codegenerierung in Form von Plug-ins für REST verfügbar, aber das ist immer noch ein zusätzlicher Schritt, der zusätzliche Komplikationen mit sich bringt.

gRPC ist ein Open-Source-Framework, das Google ursprünglich als spezifische Implementierung von Remote Procedure Call (RPC) entwickelte. Es wird jetzt von der Cloud Native Computing Foundation (CNCF) verwaltet.

Ob gRPC für „Google Remote Procedure Call“ steht, ist ungeklärt, da die Entwickler dreist darauf bestehen, dass es auch für „gRPC Remote Procedure Call“ oder verschiedene andere Möglichkeiten stehen könnte. In jedem Fall ermöglicht gRPC wie andere RPCs, dass Fernaufrufe als lokale Aufrufe erscheinen und funktionieren.

Als Modell für die Client-/Server-Interaktion wird RPC häufig in der API-Entwicklung verwendet. In einem RPC-Modell interagiert der Client mit einer zwischengeschalteten Stelle, die üblicherweise als Stub bezeichnet wird. Dieser Stub konvertiert Daten für die Übertragung und konvertiert sie, sobald er die angeforderten Ergebnisse vom Server erhält, wieder zurück in das ursprüngliche Format für den Client. Es gibt viele verschiedene Arten von RPC-Frameworks, darunter XML-RPC und JSON-RPC.

Diese RPC-Frameworks haben wenig Gewicht, sind relativ einfach verwendbar und bieten Vorteile wie z. B. eine vereinfachte Entwicklung und Abstraktion der Netzwerkkommunikation. Umgebungen wie Microservice-Architekturen und Systeme mit hohen Datenlasten benötigen jedoch häufig ein Framework mit höherer Leistung, und gRPC wurde entwickelt, um diesen Anforderungen gerecht zu werden.

gRPC verwendet eine Interface Definition Language (IDL) namens Protocol Buffers (Protobuf), um strukturierte Daten in Binärdateien zu serialisieren. Da Binärdateien kompakter sind als JSON oder XML, ermöglicht dies die Übertragung größerer Nutzlasten mit höherer Geschwindigkeit.

gRPC verwendet auch HTTP/2, das bidirektionales Streaming ermöglicht und gRPC zu einer guten Wahl für APIs in verteilten Umgebungen (insbesondere solchen, die Echtzeitkommunikation erfordern), Microservices-Architekturen, Streaming-Anwendungen und für die Verbindung von Internet der Dinge (IoT)-Geräten macht.

Geschwindigkeit: gRPC serialisiert und deserialisiert über Protobuf Daten aus vielen verschiedenen Sprachen, einschließlich Java, Python, Ruby und anderen, in eine binäre Nutzlast zur Übertragung. Dieser Code ist schlank, sodass die Übertragungszeit und die Latenz beim Datenaustausch mit gRPC-APIs reduziert werden.

Codegenerierung: gRPC enthält einen Protobuf-Compiler namens [protoc], der native Codegenerierungsfunktion bietet. Sobald die Datenstruktur in einer .proto definiert ist, kann gRPC sowohl client- als auch serverseitigen Code generieren.

HTTP/2-Unterstützung: gRPC basiert auf dem HTTP/2-Transportprotokoll und unterstützt verschiedene Arten von Streaming. Beispielsweise unterstützt es neben clientseitigem und serverseitigem Streaming auch bidirektionales Streaming, bei dem Client und Server unabhängig voneinander Nachrichten in einem Lese-/Schreibstream senden können.

Interzeptoren: gRPC unterstützt Middleware, die als Interzeptor bezeichnet wird und eine höhere Funktionalität ermöglicht. Interzeptoren können installiert werden, um Sicherheit, Authentifizierung, Metriken und mehr zu implementieren.

Abbruch und Zeitüberschreitungen: gRPC unterstützt den Abbruch, auch bekannt als Timeout oder Frist: eine bestimmte Zeit, nach der ein Anruf abgebrochen wird.

Neuigkeit und Ökosystem: gRPC enthält zwar zusätzliche Funktionen wie Codegenerierung, ist aber eine relativ neue Architektur, die erst 2016 erstmals veröffentlicht wurde. Aufgrund dieser Neuerung sind Dokumentation und Support im Vergleich zu älteren Architekturstilen begrenzt.

Steile Lernkurve: Einige Entwickler sind der Meinung, dass die Lernkurve von gRPC im Vergleich zu REST steiler ist. Die Serialisierung der Binärdaten ermöglicht eine effiziente Kommunikation, ist aber nicht für Menschen lesbar.

Mangelnde Browserunterstützung: Da Webbrowser das gRPC-Protokoll nicht nativ unterstützen, ist es nicht möglich, einen gRPC-Dienst direkt von einer browserbasierten Anwendung aus aufzurufen. Eine Möglichkeit, dieses Problem zu umgehen, ist die Verwendung eines Proxys wie gRPC-Web. gRPC-Web fungiert im Wesentlichen als Übersetzungsschicht zwischen dem HTTP- und dem gRPC-Protokoll eines Browsers.

REST und gRPC haben viele gemeinsame Elemente und werden beide zum Erstellen von skalierbaren Systemen verwendet. Zu den Ähnlichkeiten gehören:

Client-/Server-Architektur: gRPC und REST sind beides Client-/Server-Architekturen mit einem Anforderungs-Antwort-Format, das es einem Client und einem Server ermöglicht, zu kommunizieren und Daten auszutauschen. In dieser Architektur sendet ein Client eine Anfrage, und der Server antwortet, indem er angeforderte Daten zurückgibt oder eine angeforderte Aktion ausführt.

Plattformunabhängig: gRPC und REST ermöglichen die Kommunikation von Diensten, die auf unterschiedlichen Plattformen mit unterschiedlichen Betriebssystemen aufgebaut sind.

Zustandslosigkeit: Sowohl REST als auch gRPC gelten als zustandslos, was bedeutet, dass jede Anfrage alle Informationen enthält, um sie abzuschließen. Der Server muss keine Informationen zu früheren Anfragen speichern.

Sprachunterstützung: Beide Architekturstile sind sprachunabhängig, was bedeutet, dass diese APIs von Anwendungen verwendet werden können, die in verschiedenen Programmiersprachen geschrieben wurden. Diese Eigenschaft macht beide in verschiedenen Programmierumgebungen portabel.

Verwendung von HTTP: Sowohl REST als auch gRPC basieren auf HTTP-basierter Kommunikation. Allerdings verwendet gRPC HTTP/2, während REST auf HTTP/1.1 basiert. Außerdem abstrahiert gRPC das zugrunde liegende HTTP/2-Kommunikationsprotokoll, während die HTTP-Kommunikation bei REST weniger abstrahiert ist.

Die wichtigsten Unterschiede zwischen REST und gRPC können Entwicklern dabei helfen, zu entscheiden, welches für die von ihnen erstellte API am besten geeignet ist. Zu diesen Unterschieden gehören:

Datenformat: REST-APIs verwenden hauptsächlich textbasierte Formate wie JSON und XML. gRPC verwendet Protobuf, um Daten im Binärformat zu kodieren.

Kommunikationsmuster: REST unterstützt nur unäre Kommunikation, d. h. eine Anfrage gefolgt von einer Antwort. gRPC unterstützt weitere Funktionen, darunter bidirektionales Streaming (Client und Server tauschen unabhängig voneinander Daten aus), Server-Streaming (eine einzige Anfrage löst mehrere Antworten aus) und Client-Streaming (mehrere Anfragen führen zu einer einzigen Antwort).

Entwurfsmuster: gRPC hat ein serviceorientiertes Design, bei dem aufrufbare Serveroperationen als Dienste oder Funktionen definiert werden. Bei REST orientiert sich das Design an Ressourcen, wobei HTTP-Methoden verwendet werden, um über Endgeräte, die durch URLs definiert sind, auf Serverressourcen zuzugreifen.

Kopplung: Der Client und der Server von gRPC sind eng miteinander verknüpft, was bedeutet, dass sowohl der Client als auch der Server Zugriff auf dieselbe Middleware-Proto-Datei haben müssen. Jede Änderung in dem einen erfordert eine Änderung in dem anderen. REST ist lose gekoppelt. Diese Unabhängigkeit bedeutet, dass Änderungen an einer Komponente keine Auswirkungen auf die andere haben.

Codegenerierung: gRPC bietet eine integrierte Codegenerierung; REST tut dies nicht, jedoch sind Plug-ins dafür verfügbar.

Implementierung: REST erfordert keine spezielle Software und unterstützt tatsächlich Browser. gRPC erfordert sowohl auf der Server- als auch auf der Clientseite eine spezielle Software.

REST ist nicht ohne Grund eine beliebte Wahl für API-Designs. Seine Einfachheit, breite Kompatibilität und Vielseitigkeit machen es zu einer ausgezeichneten Wahl für viele Anwendungen. Für öffentliche APIs ist REST oft die sinnvollere Wahl, da es weiter verbreitet und oft leichter zu verstehen ist. Viele Entwickler sind mit REST besser vertraut und verfügen möglicherweise über eine umfangreiche Infrastruktur speziell für REST, einschließlich Servern, API-Management-Tools, Entwicklungstools und verschiedenen Testtools.

REST unterstützt auch integriertes Caching, d. h. die Möglichkeit, häufig abgerufene Daten zu speichern, sei es lokal oder über einen Proxy. Caching kann die Geschwindigkeit und Effizienz erheblich verbessern, muss aber auch verschiedene Validierungs-, Authentifizierungs- und Ablaufinformationen enthalten.

REST wird aufgrund seiner Unterstützung für HTTP/1.1 und seiner universellen Browserunterstützung auch im Allgemeinen für Webdienste und Web-APIs bevorzugt. Es wird im Allgemeinen aufgrund der einfacheren Datenkommunikation dem gRPC vorgezogen. Die lose Kopplung und die reduzierte Komplexität können die Skalierbarkeit der Systemarchitektur verbessern und dazu beitragen, eine Umgebung im Laufe der Zeit flexibler zu machen. Diese Anpassungsfähigkeit hat jedoch ihren Preis: die Leistung. 

gRPC ist eine relativ neue Architektur, deren Geschwindigkeit, Effizienz und integrierte Tools von Entwicklern zunehmend geschätzt werden. Es wird häufig für Echtzeit-Streaming-Anwendungen und komplexe APIs verwendet, die eine hohe Leistung und die Verarbeitung hoher Datenlasten in verteilten Systemen erfordern. Obwohl gRPC komplexer als REST ist, bietet die Verwendung von HTTP/2 und Protobuf eine höhere Leistung und Skalierbarkeit. 

gRPC eignet sich gut für Microservice-Architekturen, da seine Fähigkeit, bidirektionale Daten in Echtzeit zu streamen, es den verschiedenen Diensten innerhalb einer Anwendung erlaubt, gleichzeitig und unabhängig voneinander zu senden und zu empfangen. Es wird auch von mobilen Anwendungen unterstützt, da es eine schnelle, kompakte Datenübertragung ermöglicht und mobile Anwendungen seltener auf einen Browser angewiesen sind.

gRPC ist auch ideal für die Verbindung von IoT-Elementen mit Backend-APIs, da seine kompakten Nutzlasten, geringe Latenz und hohe Leistung mit Low-Power-Technologie gut kompatibel sind.