Was ist der Unterschied zwischen gRPC und REST?
gRPC und REST sind zwei Möglichkeiten, wie Sie eine API gestalten können. Eine API ist ein Mechanismus, der es zwei Softwarekomponenten ermöglicht, unter Verwendung einer Reihe von Definitionen und Protokollen miteinander zu kommunizieren. Bei gRPC ruft eine Komponente (der Client) bestimmte Funktionen in einer anderen Softwarekomponente (dem Server) auf. Bei REST ruft der Client keine Funktionen auf, sondern er fordert Daten vom Server an oder aktualisiert sie.
Was ist gRPC?
Was ist RPC?
Bei RPC funktioniert die Client-Server-Kommunikation so, als wären die Client-API-Anforderungen ein lokaler Vorgang oder die Anforderung ein interner Servercode.
Bei RPC sendet ein Client eine Anfrage an einen Prozess auf dem Server, der immer auf Remote-Aufrufe wartet. In der Anfrage enthält sie die aufzurufende Serverfunktion sowie alle zu übergebenden Parameter. Eine RPC-API verwendet ein Protokoll wie HTTP, TCP oder UDP als zugrunde liegenden Datenaustauschmechanismus.
Wie unterscheidet sich gRPC von RPC?
gRPC ist ein System, das traditionelles RPC mit mehreren Optimierungen implementiert. So verwendet gRPC beispielsweise Protokollpuffer und HTTP 2 für die Datenübertragung.
Außerdem abstrahiert es den Datenaustauschmechanismus vom Entwickler. Eine andere weit verbreitete RPC-API-Implementierung, OpenAPI, erfordert beispielsweise, dass Entwickler RPC-Konzepte auf das HTTP-Protokoll übertragen. gRPC abstrahiert jedoch die zugrunde liegende HTTP-Kommunikation. Diese Optimierungen machen gRPC schneller, einfacher zu implementieren und webfreundlicher als andere RPC-Implementierungen.
Was ist REST
REST ist ein Softwarearchitekturansatz, der eine Reihe von Regeln für den Datenaustausch zwischen Softwarekomponenten definiert. Er basiert auf HTTP, dem Standardkommunikationsprotokoll des Internets. RESTful APIs verwalten die Kommunikation zwischen einem Client und einem Server über HTTP-Verben wie POST, GET, PUT und DELETE für Erstellungs-, Lese-, Aktualisierungs- und Löschvorgänge. Die serverseitige Ressource wird durch eine URL identifiziert, die als Endpunkt bezeichnet wird.
REST funktioniert wie folgt:
- Der Client stellt eine Anfrage zum Erstellen, Ändern oder Löschen einer Ressource auf dem Server
- Die Anfrage enthält den Endpunkt der Ressource und kann auch zusätzliche Parameter beinhalten.
- Der Server reagiert und gibt die gesamte Ressource an den Client zurück, sobald der Vorgang abgeschlossen ist.
- Die Antwort enthält Daten im JSON-Format und Statuscodes.
APIs, die mithilfe von REST-Richtlinien erstellt wurden, werden RESTful APIs oder REST APIs genannt.
Warum verwenden Organisationen gRPC und REST?
gRPC und REST sind zwei verschiedene Ansätze zur Entwicklung von APIs.
Eine API funktioniert ähnlich wie eine Essensbestellung in einem Restaurant über eine Speisekarte. In jedem Restaurant kann ein Kunde (Client) Speisen von der Speisekarte (API) bestellen, die eine feste Anzahl von Gerichten enthält. Dies wird an die Küche (Server) weitergeleitet, die das gewünschte Gericht zubereitet und an den Kunden sendet. Der Kunde muss nicht wissen, wie die Küche die Bestellung ausführt, sondern nur, was er im Gegenzug erwarten kann. Die Standardisierung der Menüformate bedeutet, dass Kunden und Küchen wissen, wie sie zu verwenden sind.
Ohne APIs gäbe es keine gemeinsame Vereinbarung darüber, wie verschiedene Anwendungen oder Softwaredienste miteinander kommunizieren. Die Programmierer zweier getrennter Anwendungen müssten jedes Mal miteinander sprechen, um festzulegen, wie der Datenaustausch gestaltet werden soll.
Es gibt verschiedene Arten von API-Architekturen wie gRPC und REST, die sich für verschiedene Anwendungsfälle in einem Unternehmen besser eignen. Ein API-Designer muss seine bevorzugte Client-Server-Architektur auf der Grundlage der Systemanforderungen auswählen.
Was sind die Gemeinsamkeiten zwischen gRPC und REST?
REST und gRPC weisen als API-Architekturansätze einige inhärente Ähnlichkeiten auf.
Mechanismus für den Datenaustausch
Beide ermöglichen zwei Softwarekomponenten, einem Client und einem Server, die Kommunikation und den Datenaustausch auf der Grundlage eines gemeinsamen Regelwerks. Diese Regeln gelten unabhängig davon, wie die einzelnen Softwarekomponenten intern funktionieren.
HTTP-basierte Kommunikation
Beide übermitteln Daten über den HTTP-Anfrage-Antwort-Mechanismus, das bevorzugte effiziente Kommunikationsprotokoll des Webs. Bei gRPC ist dies jedoch für den Entwickler verborgen, während es bei REST offensichtlicher ist.
Flexibilität bei der Umsetzung
Sie können sowohl REST als auch gRPC in einer Vielzahl von Programmiersprachen implementieren. Diese Eigenschaft macht beide in hohem Maße portabel für verschiedene Programmierumgebungen. Dies führt zu einer optimalen Interoperabilität mit nahezu universeller Unterstützung.
Eignung für skalierbare, verteilte Systeme
Sowohl gRPC als auch REST verwenden Folgendes:
- Asynchrone Kommunikation, sodass Client und Server kommunizieren können, ohne den Betrieb zu unterbrechen
- Zustandsloses Design, so dass sich der Server nicht an den Zustand des Clients erinnern muss
Dies bedeutet, dass Entwickler gRPC und REST verwenden können, um fehlerresistente Systeme mit einer großen Anzahl von gleichzeitigen Anfragen zu erstellen. Sie können skalierbare, verteilte Systeme mit mehreren Clients erstellen.
Grundsätze der Architektur: gRPC vs. REST
REST und gRPC bieten zwar eine ähnliche Funktion, die zugrunde liegenden Modelle unterscheiden sich jedoch erheblich in ihrer Architektur.
Kommunikationsmodell
Mithilfe einer REST-API sendet ein Client eine einzelne REST-API-Anfrage an einen Server und der Server sendet dann eine einzige Antwort als Antwort. Der Client muss die Antwort des Servers abwarten, bevor er den Vorgang fortsetzt. Bei diesem Mechanismus handelt es sich um ein Anfrage-Antwort-Modell und um eine unäre Datenverbindung (eins-zu-eins).
Im Gegensatz dazu kann ein Client bei gRPC eine oder mehrere API-Anfragen an den Server senden, die zu einer oder mehreren Antworten des Servers führen können. Datenverbindungen können unär (eins-zu-eins), Server-Streaming (eins-zu-viele), Client-Streaming (viele-zu-eins) oder bidirektionales Streaming (viele-zu-viele) sein. Dieser Mechanismus ist ein Client-Response-Kommunikationsmodell und ist möglich, da gRPC auf HTTP 2 basiert.
Aufrufbare Operationen auf dem Server
In einer gRPC-API werden aufrufbare Serveroperationen durch Services definiert, die auch als Funktionen oder Verfahren bezeichnet werden. Der gRPC-Client ruft diese Funktionen auf, als würden Sie eine Funktion intern innerhalb einer Anwendung aufrufen. Dies wird als serviceorientiertes Design bezeichnet. Beispiel:
createNewOrder(customer_id, item_id, item_quantity) -> order_id
In REST gibt es eine begrenzte Anzahl von HTTP-Anforderungsverben, die der Client auf Serverressourcen verwenden kann und die durch eine URL definiert sind. Der Client ruft die Ressource selbst auf. Dies wird als entitätsorientiertes Design bezeichnet. Das entitätsorientierte Design passt gut zu objektorientierten Programmiermethoden. Beispiel:
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
Sie können gRPC-APIs in einem entitätsorientierten Ansatz entwerfen, dies ist jedoch keine Beschränkung des Systems selbst.
Format des Datenaustauschs
Bei einer REST-API werden die zwischen Softwarekomponenten übergebenen Datenstrukturen typischerweise im JSON-Datenaustauschformat ausgedrückt. Es ist möglich, andere Datenformate wie XML und HTML zu übergeben. JSON ist einfach zu lesen und flexibel, obwohl es serialisiert und in eine Programmiersprache übersetzt werden muss.
Im Gegensatz dazu verwendet gRPC standardmäßig das Protocol-Buffers-(Protobuf)-Format, obwohl es auch native JSON-Unterstützung bietet. Der Server definiert eine Datenstruktur mit Hilfe der Protocol Buffer Interface Description Language (IDL) in einer Proto-Spezifikationsdatei. gRPC serialisiert die Struktur dann in ein Binärformat und deserialisiert sie anschließend in eine beliebige Programmiersprache. Dieser Mechanismus beschleunigt das Verfahren im Vergleich zur Verwendung von JSON, das bei der Übertragung nicht komprimiert wird. Protokollpuffer sind im Gegensatz zu einer REST-API, die mit JSON verwendet wird, nicht für Menschen lesbar.
Weitere wichtige Unterschiede: gRPC vs. REST
Weitere wichtige Unterschiede: gRPC vs. REST
Neben dem architektonischen Stil weisen gRPC und REST noch weitere inhärente Unterschiede auf.
Client-Server-Verkopplung
REST ist lose gekoppelt, was bedeutet, dass der Client und der Server nichts über die Implementierung des anderen wissen müssen. Diese lose Verkopplung erleichtert die Weiterentwicklung der API im Laufe der Zeit. Dies liegt daran, dass eine Änderung der Serverdefinitionen nicht unbedingt eine Codeänderung auf dem Client erfordert.
gRPC ist eng gekoppelt, was bedeutet, dass der Client und der Server Zugriff auf dieselbe Proto-Datei haben müssen. Alle Aktualisierungen der Datei erfordern Aktualisierungen sowohl auf dem Server als auch auf dem Client.
Code-Generierung
gRPC bietet eine integrierte Auswahl an client- und serverseitigen Featureszur Erzeugung von nativem Code. Sie sind dank protoc, dem Protocol Buffers Compiler, in mehreren Sprachen verfügbar. Nach der Definition der Struktur in der Proto-Datei generiert gRPC den clientseitigen und serverseitigen Code. Die Codegenerierung macht die API-Entwicklung weniger zeitaufwändig.
Andererseits bietet REST keine eingebauten Mechanismen zur Codegenerierung, so dass Entwickler zusätzliche Tools von Drittanbietern verwenden müssen, wenn sie dieses Feature benötigen. Erfahren Sie mehr über die Code-Generierung.
Bidirektionales Streaming
gRPC bietet bidirektionale Streaming-Kommunikation. Das bedeutet, dass sowohl der Client als auch der Server mehrere Anfragen und Antworten gleichzeitig über eine einzige Verbindung senden und empfangen können.
REST bietet dieses Feature nicht.
Wann sollte gRPC verwendet werden vs. REST
REST ist derzeit die beliebteste API-Architektur für Webdienste und Microservice-Architekturen. Die Beliebtheit von REST ist auf seine einfache Implementierung und Datenstrukturabbildung, Lesbarkeit und Flexibilität zurückzuführen. Für neue Programmierer ist es einfach, mit der Entwicklung von RESTful-APIs für ihre Anwendungen zu beginnen, sei es für die Entwicklung von Webdiensten oder internen Microservices.
Hier sind Anwendungsfälle für eine REST-API:
- Webbasierte Architekturen
- Öffentlich zugängliche APIs zum besseren Verständnis für externe Nutzer
- Einfache Datenkommunikation
gRPC wurde im Gegensatz zu REST speziell entwickelt, um Entwicklern die Erstellung leistungsstarker APIs für Microservice-Architekturen in verteilten Rechenzentren zu ermöglichen. Es eignet sich besser für interne Systeme, die Echtzeit-Streaming und große Datenmengen erfordern. gRPC eignet sich auch gut für Microservice-Architekturen, die mehrere Programmiersprachen umfassen, wenn es unwahrscheinlich ist, dass sich die API im Laufe der Zeit ändert.
Eine gRPC-API ist für diese Anwendungsfälle besser geeignet:
- Hochperformante Systeme
- Hohe Datenlasten
- Echtzeit- oder Streaming-Anwendungen
Eine Anmerkung zur Entwicklung von Web-Software
HTTP ist zwar das zentrale Webprotokoll, aber es gibt verschiedene Versionen von HTTP, die in Webbrowsern und Webservern unterschiedlich weit verbreitet sind.
Eine gRPC-API verwendet immer HTTP 2, während eine REST-API normalerweise HTTP 1.1 verwendet, was nicht dasselbe HTTP-Protokoll ist. HTTP 2 ist zwar inzwischen ein gängiges Webprotokoll, wird aber im Gegensatz zu HTTP 1.1 nicht von allen Browsern unterstützt. Diese begrenzte Browserunterstützung kann gRPC zu einer weniger attraktiven Option für Entwickler machen, die Webanwendungen unterstützen möchten.
Zusammenfassung der Unterschiede: gRPC vs. REST
| gRPC API |
REST-API |
|
| Wie lautet es? |
Ein System zur Erstellung und Verwendung von APIs auf der Grundlage des Client-Server-Kommunikationsmodells Remote Procedure Call (RPC). |
Ein Regelwerk, das den strukturierten Datenaustausch zwischen einem Client und einem Server definiert. |
| Design-Ansatz |
Serviceorientiertes Design. Der Client fordert den Server auf, einen Service oder eine Funktion auszuführen, die sich auf die Serverressourcen auswirken kann oder auch nicht. |
Entitätsorientiertes Design. Der Client fordert den Server auf, Ressourcen zu erstellen, gemeinsam zu nutzen oder zu ändern. |
| Kommunikationsmodell |
Mehrere Optionen wie unär, ein Server für viele Clients, ein Client für viele Server und viele Clients für viele Server. |
Unär. Ein einzelner Client kommuniziert mit einem einzelnen Server. |
| Implementierung |
Für den Betrieb ist gRPC-Software sowohl auf der Client- als auch auf der Serverseite erforderlich. |
Sie können es auf der Client- und Serverseite in einer Vielzahl von Formaten implementieren, ohne dass eine gemeinsame Software erforderlich ist. |
| Datenzugriff |
Service-(Funktions-)Aufrufe. |
Mehrere Endpunkte in Form von URLs zur Definition von Ressourcen. |
| Zurückgegebene Daten |
In der festen Rückgabeart des Services, wie in der Protokollpufferdatei definiert. |
In einer festen Struktur (normalerweise JSON), die vom Server definiert wird. |
| Client-Server-Verkopplung |
Eng gekoppelt. Sowohl Client als auch Server benötigen dieselbe Protokollpufferdatei, die das Datenformat definiert. |
Lose gekoppelt. Client und Server wissen nichts über interne Details. |
| Automatische Codegenerierung |
Integriertes Feature. |
Erfordert Tools von Drittanbietern. |
| Bidirektionales Streaming |
Vorhanden. |
Nicht vorhanden. |
| Am besten geeignet für |
Hochleistungs- oder datenintensive Microservice-Architekturen. |
Einfache Datenquellen, bei denen die Ressourcen klar definiert sind. |
Wie kann AWS Ihre gRPC- und REST-Anforderungen unterstützen?
Amazon Web Services (AWS) verfügt über eine Reihe von Services und Tools, die API-Designer bei der Erstellung, Ausführung und Verwaltung API-basierter moderner Anwendungen und Services unterstützen. Weitere Informationen finden Sie unter Erstellen moderner Anwendungen in AWS.
Hier finden Sie Beispiele für AWS-Angebote, die Ihre API-Anforderungen unterstützen können:
- Amazon API Gateway ermöglicht es Entwicklern, APIs in großem Maßstab zu erstellen, zu veröffentlichen und zu verwalten. Mit API Gateway können Sie RESTful-APIs erstellen, die für containerisierte Microservice-Architekturen und Webanwendungen optimiert sind.
- Elastic Load Balancing (ELB) verteilt den Netzwerkverkehr, um die Skalierbarkeit von Anwendungen zu verbessern. Die Anwendung kann den gRPC-Datenverkehr zwischen Microservices oder zwischen gRPC-fähigen Clients und Services routen und ausgleichen. Dies ermöglicht die nahtlose Einführung des gRPC-Datenverkehrsmanagements in die Architekturen, ohne die zugrunde liegende Infrastruktur auf den Clients oder Services der Kunden zu verändern.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice ist ein Anwendungsnetzwerkservice, der die Kommunikation zwischen Ihren Diensten konsistent verbindet, überwacht und sichert. Skalieren Sie Rechen- und Netzwerkressourcen automatisch, um HTTP-, HTTPS- und gRPC-Workloads mit hoher Bandbreite zu unterstützen.
Beginnen Sie mit gRPC und REST in AWS, indem Sie noch heute ein Konto erstellen.
