Wie Sie sich zwischen REST und gRPC entscheiden

Die Popularität von REST

In der heutigen Entwicklungswelt ist es üblich, dass ein Unternehmen eine öffentliche REST API publiziert und diese in anderen Anwendungen von Drittanbietern verwendet wird. So veröffentlichen beispielsweise die New York Times und das US-Handelsministerium weit verbreitete REST APIs, die auch extern genutzt werden.

Trotz dieser Beliebtheit hat REST jedoch Probleme. Das gilt insbesondere in Bezug auf die Standardisierung, den Leistungs-Overhead und die Streaming-Fähigkeiten für Web-Service-Clients. An dieser Stelle kommt gRPC ins Spiel.

Das von Google entwickelte gRPC ist ein API-Protokoll, das für Anwendungen gedacht ist, die Daten schnell und kontinuierlich abrufen müssen. gRPC ist zwar nicht so einfach zu verwenden wie REST – doch die potenziellen Vorteile rechtfertigen es, sich stärker damit zu beschäftigen.

Wie funktioniert REST?

Representational State Transfer (REST) ist ein bestimmter Architekturstil. Er nutzt HTTP als Standard-Kommunikationsprotokoll für Ressourcen, die mit APIs definiert werden. Eine Ressource können Sie sich als eine Entität vorstellen ähnlich einem Objekt, wie es in der objektorientierten Programmierung (OOP) verwendet wird.

Genau wie ein Objekt in einer solchen Programmiersprache verfügt eine RESTful-Ressource über Eigenschaften und Verhaltensweisen. Die meisten REST-Implementierungen konzentrieren sich eher auf die Eigenschaften einer Ressource und berücksichtigen das RESTful-Verhalten nur wenig. Implementierungen, die eine RESTful-Ressource nur in Bezug auf ihre Eigenschaften beschreiben, gelten als RESTful.

REST APIs und HTTP

Unter REST wird eine Ressource oder eine Sammlung von Ressourcen durch eine URL beschrieben. Die folgende Beispiel-URL beschreibt eine Sammlung von Tier-Ressourcen, die über eine fiktiv benannte API auf example.com verfügbar sind.

https://api.example.com/tiere

REST macht sich die HTTP-Spezifikation zunutze, um das Abrufen, Hinzufügen, Ändern und Löschen einer Quelle in einem bestimmten Bereich mit Hilfe der HTTP-Verben GET, POST, PUT, PATCH und DELETE zu realisieren. Die folgende Tabelle 1 zeigt die von Entwicklern am häufigsten verwendeten HTTP-Methoden.

RESTful-Ressourcen

Wenn Sie – unter Verwendung der oben beschriebenen Tier-Ressourcen – alle in der API unter api.mysimpleapi.com verfügbaren Tiere mit Unterstützung des Befehlszeilenprogramms curl abrufen möchten, müssen Sie folgende Anweisung in einem Terminalfenster ausführen:

curl https://api.mysimpleapi.com/tiere

Wenn Sie der API ein Tier hinzufügen möchten, könnten Sie mit curl eine POST-Anfrage an die API stellen, etwa so:

curl -d ' {"Spezies": "Hund", "Rasse": Poodle, "Beine": 4 }' -H "Content-Type: application/json" -X POST

https://api.mysimpleapi.com/tiere

Wichtig ist es dabei, zu verstehen, dass die REST-Architektur für den Informationsaustausch HTTP als Mittel für Anfragen an eine REST-API verwendet. Entwickler können Daten mit den Standard-HTTP-Methoden GET, POST, PUT, PATCH und DELETE abrufen, hinzufügen, ändern und löschen.

Datenaustauschformate für Webdienste

REST ist schon seit Jahrzehnten im Einsatz. Im Laufe der Zeit hat sich eine bestimmte Konvention für die Definition von URLs herausgebildet. In der Regel beschreibt die Basis-URL für eine Ressource die Sammlung von Ressourcen, zum Beispiel:

/tiere/

Dieser URL-basierte Verweis auf eine RESTful-Ressource gibt alle Tier-Ressourcen in einem Datenaustauschformat wie JSON zurück:

[

{ "id": 501, "Spezies": "Hund", "Rasse": "Terrier", "Beine": 4 },

{ "id": 502, " Spezies ": "Vogel", "Art": "Robin", " Beine ": 2 },

]

Das herkömmliche Format zum Abrufen einer bestimmten Ressource innerhalb der Sammlung besteht darin, den eindeutigen Bezeichner der jeweiligen Ressource als Teil der URL-Definition festzulegen, etwa so:

/tiere /{id}

Dabei ist {id} der Platzhalter für den tatsächlichen eindeutigen Bezeichner.

Um also ein bestimmtes Tier über die API von example.com abzurufen, wird die URL wie folgt geschrieben:

https://api.mysimpleapi.com/tiere/501

Das Ergebnis einer GET-Anfrage an die fiktive Animals-API unter der oben angegebenen URL lautet dann:

{ "id": 501, "Spezies": "Hund", "Rasse": "Terrier", "Beine": 4 }

Abbildung 2 zeigt die Details zum Abrufen einer bestimmten Ressource.

Strukturen für RESTful-Ressourcen

Bei REST muss das Format für den Datenaustausch nicht angegeben werden, bevor eine Ressource über das Netzwerk gesendet wird. Solange eine REST API Daten in einem akzeptablen Format wie JSON, YAML oder XML ausgibt, können Entwickler eine API nach Belieben definieren.

Im Laufe der Jahre gab es den Trend, die Definition von REST-Ressourcen zu formalisieren. In der Specification First-Bewegung beispielsweise spezifiziert ein Entwickler zunächst die API über ein Spezifikationsformat wie OpenAPI oder API Blueprint. Anschließend erstellt der Entwickler die API auf Basis dieser Spezifikation. Dazu muss man sagen: Eine referenzierbare Spezifikation ist zwar gut, aber nicht unbedingt erforderlich.

Ein verantwortungsbewusster Entwickler veröffentlicht eine Dokumentation, in der jede Datenstruktur jeder Ressource in der API mit einem der vielen beliebten Dokumentations-Tools wie SwaggerHub beschrieben wird. (Meine Flughafencode-API auf SwaggerHub ist ein Beispiel dafür.) Manchmal publiziert ein Entwickler ein Dokument, das die API als Read.me-Datei in einem Quellcode-Repository wie GitHub beschreibt.

Und dann gibt es Zeiten, in denen ein Entwickler diese API überhaupt nicht dokumentiert – mit der Konsequenz, dass Sie es selbst herausfinden müssen. Ich halte dieses Vorgehen für verantwortungslos – aber eine solche Verantwortungslosigkeit kommt glücklicherweise selten vor. In diesen Fällen kann der Verbraucher zumindest die URL einer REST API auf einer Trial-and-Error-Basis abfragen, um nach verfügbaren Informationen zu suchen.

Ein Entwickler kann die API aufrufen, und das Ergebnis liegt in einem bekannten Textformat wie JSON oder XML vor. Eine besondere Dechiffrierung ist nicht erforderlich - es ist alles Text, die ganze Zeit.

Die Verwendung eines Textformats ist jedoch mit einem gewissen Aufwand verbunden. Das Senden und Empfangen von Text über ein Netzwerk kann kostspielig sein. Jedes Zeichen in einer Folge von Textzeichen ist ein Byte, so dass die folgende JSON-basierte Textzeichenfolge 62 Byte an Netzwerkdaten verbraucht:

{ "id": 501, "Spezies": "Hund", "Rasse": "Terrier", "Beine": 4 }

Wenn eine API eine einzelne Ressource veröffentlicht, ist das ist keine große Sache. Was aber passiert, wenn eine API Millionen von Ressourcen in einer Sammlung publiziert? Der Overhead kann beträchtlich werden. An dieser Stelle kommt gRPC zum Einsatz.

Wie gRPC funktioniert

gRPC wurde mit dem Ziel eingeführt, eine schnelle und effiziente Kommunikation zwischen einer Quelle und einem Ziel zu ermöglichen. Es basiert auf der RPC-Architektur, bei der eine Quelle eine vordefinierte Prozedur auf dem Ziel – in der Regel ein Endpunkt – aufruft.

Sowohl die Prozedur als auch die an eine Prozedur gesendeten Nachrichten werden in einer Spezifikationsdatei definiert. In gRPC hat die Spezifikationsdatei die Erweiterung .proto.

Der folgende Code zeigt ein Beispiel für die Spezifikationsdatei animal.proto. Das Listing definiert eine Methode, GetAnimal(), sowie zwei Nachrichten, AnimalRequest und Animal.

Beide Nachrichten werden in der Spezifikation für die Methode GetAnimal() verwendet. Ein Aufrufer, der die Methode GetAnimal() nutzt, liefert eine Animal-ID über die Nachricht AnimalRequest. Die Methode GetAnimal() gibt ein Tier entsprechend der ID im Format einer Animal-Nachricht zurück.

package animalpackage;

syntax = "proto3";

service AnimalCatalog {

// Sendet einen Gruß

rpc GetAnimal (AnimalRequest) returns (Animal) {}

}

// definiert eine Anfrage für ein Tier

message AnimalRequest {

int32 id = 1;

}

// definiert ein Tier

message Animal {

int32 id = 1;

string species = 2;

string breed = 3;

int32 legs = 4;

}

Die wesentliche Dynamik von gRPC besteht darin, dass eine Quelle eine Prozedur auf einem Ziel – mit einer vordefinierten Nachricht – aufruft und eine Antwort von dieser Prozedur erhält.

Die Serialisierung von Protokollpuffern unter gRPC verstehen

Neben einer vereinfachten Syntax für Methodenaufrufe ermöglicht gRPC auch eine verbesserte Leistung. Der Grund dafür ist, dass es den Datenaustausch effizienter macht. Die wichtigste Art und Weise, wie gRPC diese Vereinfachung handhabt, ist das binäre Serialisierungsformat für Protokollbuffer.

Client-Anwendungen, die gRPC unterstützen, kodieren Daten in Datenbytes gemäß der Codierungslogik für die Protokollbuffer. Diese codieren die Nachricht in ein binäres Format. Der Client sendet die Daten an Server, die wissen, dass Daten über Protokollbuffer ausgetauscht werden.

Nachdem der Server die Anfrage verarbeitet hat, kodiert er eine Antwort gemäß dem Serialisierungsformat von Protokollbuffern und sendet diese Bytes zurück an den Client. Der Client empfängt und entschlüsselt dann die Antwort des Servers.

Eine REST-animal-Ressource mit diesen Informationen wäre zum Beispiel 62 Byte groß und würde wie folgt aussehen:

{ id: 501, Spezies: Hund, Rasse: 'Terrier', Beine: 4}

Die gleiche JSON-Zeichenfolge, die mit Protokollbuffern kodiert wurde, ergibt ein Byte-Array, das die folgende Gestalt hat und nur neun Byte groß ist:

08 f5 03 12 03 44 6f 67 1a 07 54 65 72 72 69 65 72 20 04

Trotz des vereinfachten Formats und der geringeren Größe ist gRPC nicht für jede Situation geeignet.

REST versus gRPC

REST als auch gRPC haben beide ihren Platz in der IT-Landschaft – mit jeweils spezifischen Vor- und Nachteilen.

In Bezug auf die Benutzerfreundlichkeit gewinnt REST haushoch. Wenn Entwickler eine REST API verwenden, entspricht dies im Wesentlichen dem Aufruf einer Webseite. Um eine REST API zu erstellen, benötigen Entwickler lediglich eine integrierte Entwicklungsumgebung, in der sie einen Webserver erstellen und starten. Um eine REST API zu nutzen, kann jeder Entwickler ein kostenloses Tool wie Postman oder cURL verwenden. Damit lassen sich HTTP-Aufrufe für einen Endpunkt konfigurieren und ausführen.

Der Nachteil von REST: REST ist sperrig und zustandslos. Eine REST-Antwort sendet eine Menge Daten über das Netzwerk, und das meiste davon hat mit der Datenstruktur zu tun und nicht mit den eigentlichen Daten selbst.

In REST können Entwickler keine Verbindung zu einem Ziel herstellen und dann dafür sorgen, dass das Ziel kontinuierlich Daten über diese Verbindung zurücksendet. Die Entwickler müssen in regelmäßigen Abständen die API aufrufen, um diese Daten zu erhalten.

gRPC auf der anderen Seite ist hingegen so konzipiert, dass es kontinuierliches Streaming unterstützt. Es verwendet das HTTP/2-Protokoll – und dieses Protokoll beinhaltet den integrierten Streaming-Support. Mit HTTP/2 können Entwickler eine Verbindung zu einem gRPC-fähigen Server herstellen. Diesen Server können sie dann veranlassen, kontinuierlich serialisierte Daten in Protokollbuffern an den Client zurückzusenden.

Der Nachteil von gRPC ist, dass Entwickler eine Menge Konzepte und Operationen kennen müssen, um es zu nutzen. Zum Beispiel müssen sowohl der Client als auch der Server die Spezifikation der .proto-Datei kennen. Beide verwenden diese Informationen, um die Kodierung und Dekodierung mit Protokollbuffern durchzuführen. Im Gegensatz zu REST können Entwickler einen Aufruf nicht ausführen, indem sie eine URL in ein Tool eingeben und ein Ergebnis in JSON zurückerhalten.

Sowohl auf dem Client als auch auf dem Server sind zahlreiche Kodierungs- und Dekodierungsvorgänge erforderlich, um mit der Serialisierung von Protokollbuffern zu arbeiten. Diese Kodierung und Dekodierung verbraucht Rechenressourcen, führt jedoch zu einem blitzschnellen Datenaustausch.

Sie müssen sich darüber im Klaren sein, dass Sie bei gRPC viel mehr Arbeit leisten müssen, um die Daten für die Nutzung sinnvoll aufzubereiten. Bei REST hingegen ist das, was Sie sehen, auch das, was Sie bekommen.

Sollten Sie REST oder gRPC verwenden?

Als REST vor mehr als zwei Jahrzehnten zum ersten Mal auftauchte, war es eine revolutionäre Architektur. Sie standardisierte den Datenaustausch und erleichterte es den Entwicklern, die benötigten Daten auf bekannte und zuverlässige Weise zu erhalten. Ohne REST wäre das, was als API-Economy bezeichnet wird, wahrscheinlich nicht möglich.

Dennoch hatte REST einen Nachteil für Entwickler von Microservices – vor allem für diejenigen, die sich nach Geschwindigkeit sehnen. Die große Masse der REST-Antworten kann eine Belastung für das Netzwerk darstellen. Wenn man genug Text in eine REST-Nachricht packt, kann es schnell langsam werden.

Für alle, denen Geschwindigkeit wichtig ist, gibt es gRPC. Der Nachteil von gRPC ist, dass man viel wissen muss, um es zu benutzen. Die IT-Abteilung muss abwägen, ob die Vorteile den Aufwand rechtfertigen, den gRPC erfordert.

Keine der beiden Architekturen kann für jeden alles sein. Die IT-Branche ist so groß und komplex, dass es keine einheitliche Technologie für den Datenaustausch gibt, die Geschwindigkeit und Benutzerfreundlichkeit vereint. Bis es so weit ist, sollten Sie sich mit den Grundlagen von REST UND gRPC vertraut machen. Dann finden Sie auch die passende Lösung für Ihr Unternehmen.