REST, GraphQL und gRPC Vergleich Teil 2: Paradigmen, Konzepte & Architektur
Von: Thomas Bayer
Datum: 31. Jan. 2021
Aktualisiert: 9. April 2021
REST, GraphQL und gRPC dienen dem Austausch von Nachrichten über das HTTP bzw. HTTP/2 Protokoll. Abgesehen von dieser Gemeinsamkeit sind die Paradigmen der drei Technologien grundverschieden. gRPC ist wie der Name bereits verrät ein moderner Vertreter der Remote Procedure Calls, in GraphQL steht das QL für Query-Language und REST basiert auf der Architektur des Webs.
Dieser Teil beschreibt die unterschiedlichen Paradigmen. Die übrigen Teile dieses Artikels behandeln die folgenden Themen:
- Teil 1: Einführung
- Teil 3: Formate
- Teil 4: Schnittstellenbeschreibung mit OpenAPI, IDL & GraphQL Schema
- Teil 5: Streaming
- Teil 6: Performanz
- Teil 7: Plattformen und Programmiersprachen
1. Der Architekturstil REST
REST basiert auf der Architektur des World Wide Webs und verspricht, dass Anwendungen von den Vorteilen des Webs wie z.B. Skalierbarkeit und Dezentralisierung profitieren können.
Bei REST geht es um die Abfrage und Manipulation von Geschäftsobjekten über Ressourcen. Jede Ressource hat einen Namen, die URI. Beispielsweise könnte ein Produkt eines Shops die folgende URI besitzen:
Der Link ist gleichzeitig die Adresse und der Name eines Geschäftsobjektes. Wenn du auf den Link klickst, solltest du eine Kopie der Daten, die bei REST Repräsentation genannt wird, angezeigt bekommen. Die Repräsentation ist Teil des Namens: Representational State Transfer.
Die Abfrage und Manipulation von Ressourcen erfolgt über eine begrenzte Anzahl von Methoden, meist sind es nicht mehr als GET, POST, PUT und DELETE. Als Ausgleich gibt es einen großen Gestaltungsspielraum bei der Vergabe von Namen für die Ressourcen, also für die URIs bzw. Pfade.
Das Ändern einer Ressource erfolgt über das Senden einer Repräsentation mit neuen Inhalten. Eine Repräsentation ist nichts anderes als eine Kopie der Daten eines Geschäftsobjektes. Das Beispiel unten zeigt einen HTTP-Request, der ein neues Produkt anlegt. Die URL adressiert die Ressource und das JSON Dokument im HTTP Body ist die Repräsentation.
POST https://api.predic8.de/shop/products/
Content-Type: application/json
{
"name": "Tollkirsche",
"preis": 7.99
}
Für eine Repräsentation kann ein beliebiges Datenformat verwendet werden. Neben JSON und XML können auch Binärformate wie z.B. PDF oder Bilder übertragen werden.
Die Konzepte von HTTP werden bei REST selbst auf der Anwendungsebene verwendet. Beispielsweise werden die HTTP Status Codes als Errorcodes verwendet. Wird bei einer Anfrage ein Geschäftsobjekt nicht gefunden, so antwortet der Server mit dem Status Code:
Im Web bedeutet dieser Code, dass es die angefragte Seite nicht gibt. Bei REST wird das Netzwerkprotokoll nicht vor der Anwendung verborgen, sondern es wird bewusst als Gestaltungsmittel eingesetzt und ist im Code der Anwendung als Status Code oder HTTP Header sichtbar.
2. GraphQL
GraphQL ist mit der Datenbankabfragesprache SQL vergleichbar. Der Client hat bei der Formulierung seiner Abfragen einen großen Spielraum und der Server interpretiert die Anfrage, um die gewünschte Antwort zu erzeugen. Analog zu den Datenbanken, gibt es bei GraphQL Beziehungen zwischen Objekten, die wie bei einem Join mit einer Abfrage verfolgt werden können.
In der folgenden Abfrage wird neben dem Preis und dem Namen auch nach dem Ort des Herstellers gefragt. Um die Frage beantworten zu können, muss der Server die Beziehung zwischen Produkt und Hersteller kennen und darüber navigieren können.
POST /shop/graphql
{
produkte {
name
preis
hersteller {
ort
}
}
}
Mit REST oder gRPC müssten dafür zwei Aufrufe hintereinander ausgeführt werden. Bei GraphQL können die meisten Aufgaben effizient mit nur einem Aufruf erledigt werden. GraphQL eignet sich daher für limitierte Netzwerkverbindungen zum Bespiel für mobile Anwendungen und Apps.
Analog zu SQL ist GraphQL nicht auf die Abfrage von Daten beschränkt, das Anlegen und Ändern ist ebenfalls möglich.
3. Google RPC
Wie der Name bereits sagt, geht es bei gRPC um entfernte Funktionsaufrufe. Weitere Verwandte dieser Gattung sind die SOAP basierten Web Services, SAP RFC oder CORBA. Nachdem die Remote Procedure Calls einige Jahre außer Mode waren, kommen Sie mit einer modernisierten Variante von Google zurück. Mehr Informationen zu dem Remote Procedure Calls findest du unten in der Box.
Für die Übertragung von gRPC Aufrufen wird das HTTP/2 Protokoll verwendet. Im Gegensatz zu REST kommt der Entwickler mit HTTP direkt nicht in Verbindung. Das Ansprechen des Netzwerkes ist bei gRPC in den aus der Schnittstellenbeschreibung generierten Klassen verborgen.
Was ist ein Remote Procedure Call?
Über Remote Procedure Calls können Anwendungen Funktionen bereitstellen, die über das Netzwerk von anderen Rechnern aufgerufen werden. Für RPC gibt es diverse Standards und herstellerspezifische Lösungen wie z.B. gRPC oder Java RMI.
Ein Funktionsaufruf auf einem entfernten Computer sieht im Programmcode genauso aus, wie der Aufruf einer lokalen Funktion. Beim Aufruf einer lokalen oder einer entfernten Funktion werden Parameter übergeben und ein Rückgabewert erwartet:
Das Diagramm unten zeigt einen Service, der Funktionen für Kundenobjekte zur Verfügung stellt.
Abbildung :
Um entfernte Funktionsaufrufe einrichten zu können muss bei vielen RPC Technologien wie z.B. gRPC oder Java RMI ein Dokument mit einer Schnittstellenbeschreibungssprache vorhanden sein. Die Verwendung einer Schnittstellenbeschreibung ist typisch für RPC-Technologien.
Aus der Beschreibung können Klassen für alle in der Schnittstellen verwendeten Datentypen generiert werden. Diese Klassen erleichtern dem Entwickler die Erstellung eines Clients oder Servers für die jeweilige Technologie. Mehr zum Thema Schnittstellenbeschreibung findest du im 5. Teil dieser Reihe.
4. Fazit
REST, GraphQL und gRPC basieren auf unterschiedlichen Paradigmen.
Bei gRPC ist das Netzwerk komplett verborgen und der Programmierer kommt mit dem Netzwerk selbst nicht in Berührung. Die Abstraktion ist eine Funktion.
Das Netzwerk ist bei REST in Form von HTTP Methoden, URIs und Statuscodes auf Anwendungsebene sichtbar. Der Programmierer muss für die Nutzung oder den Entwurf von APIs über gute HTTP Kenntnisse verfügen. Dafür gibt es für viele Probleme wie z.B. für Caching oder den Umgang mit verschiedenen Datenformaten Lösungen, die von HTTP bereitgestellt werden.
GraphQL nutzt HTTP für die Übertragung, verwendet aber die Konzepte von HTTP nicht. Beispielsweise wird jeder Aufruf an den selben Endpunkt geschickt, als Folge ist ein Caching auf Netzebene nicht möglich. Mit GraphQL sind dafür flexible Abfragen möglich, die in begrenzten mobilen Netzwerken Zeit sparen. Für die Manipulation von Daten setzt GraphQL genauso wie gRPC auf das Remote Procedure Call Paradigma.