GraphQL im Vergleich mit REST

REST

REST steht für Representational State Transfer. Dabei handelt es sich um ein Architekturprinzip für Schnittstellen, welches sich an den Paradigmen des World Wide Web (www) orientiert. Das Konzept wurde von Dr. Roy Fielding entwickelt und im Jahr 2000 vorgestellt. [1]

Der Architekturstil setzt 6 Prinzipien voraus [2]:

• • Client-Server-Modell: Das Nutzerinterface soll von den Daten getrennt sein.
  • Zustandslosigkeit: Client und Server müssen zustandslos miteinander kommunizieren.
  • Caching: Informationen können als cacheable oder non-cacheable spezifiziert werden.
  • Einheitliche Schnittstelle: REST-Konforme und einheitliche Schnittstellen.
  • Mehrschichtige Systeme: REST setzt auf mehrschichtige und hierarchisch aufgebaute Systeme, die streng voneinander abgegrenzt sind.
  • Code-On-Demand: Erweiterbarkeit der Funktionen (optional).

REST adressiert Daten mittels sogenannter Ressourcen. [3] Diese Ressourcen werden für die Abstraktion von Informationen genutzt. Informationen, die als Ressource definiert werden können, sind unter anderem Dokumente, Bilder und Daten wie beispielsweise Personendaten. [4]

Es werden Endpunkte definiert, um die Ressourcen eindeutig identifizieren zu können. [4]

Diese Endpunkte sind in der Regel URLs. Im Normalfall besitzen REST APIs mehrere Endpunkte mit jeweils unterschiedlichen URLs. Die Endpunkte der REST API können über eine definierte Auswahl der verfügbaren http-Methoden angesprochen werden. Genutzte Methoden sind z.B. GET, POST, UPDATE und DELETE.

Ein Beispiel Endpunkt wäre http://localhost:8080/persons. Mit diesem Endpunkt könnten beispielsweise Personendaten abgefragt werden.

Eine häufig auftretende Schwachstelle von REST APIs ist das Over- und Underfetching. Beim Overfetching werden mehr Informationen an den Client zurückgegeben, als angefordert wurden. Z.B. möchte ein Client nur den Namen einer Person, erhält aber alle weiteren Informationen wie Geburtsdatum, Telefonnummer, Wohnort, usw. zusätzlich. Im Gegensatz dazu erhält der Client beim Underfetching nicht genügend Informationen. So möchte ein Client z.B. den Namen einer Person und die Adresse dieser Person. Dafür müssten zwei Anfragen an den Server gestellt werden. Ein einzelner reicht nicht aus, um alle Informationen zu erhalten. Das bedeutet längere Übertragungszeiten und dadurch schlechtere Performance. [5]

GraphQL

GraphQL wurde von Facebook entwickelt und 2012 erstmals in Mobilanwendungen eingesetzt. 2015 wurde GraphQL als Open Source-Lösung veröffentlicht. Mittlerweile wird es von der GraphQL Foundation betreut. [6] Bei GraphQL handelt es sich um eine Query Language und eine serverseitige Runtime, die zur Bearbeitung der Anfragen dient. [6][7, S. 2]

Im Gegensatz zu den Ressourcen von REST nutzt GraphQL Knoten. Es baut einen Graphen mit allen vorhandenen Daten auf, sodass von einem zum nächsten Knoten gesprungen werden kann. Bei den Knoten handelt es sich um typisierte Daten mit ihren jeweiligen Feldern. Wie diese Knoten definiert sind, wird durch die Schema Language bestimmt. Die Startknoten, bei denen der Client einsteigen kann, werden im Schema definiert. [3]

Beispiel:

type Person {
  id: ID!
  name: String!
  city: [city]
}

GraphQL verwendet dabei nur einen einzigen Endpunkt (z.B. http://localhost:4000/graphql).

Dieser wird sowohl für das Lesen, als auch für das Schreiben, Ändern und Löschen von Daten genutzt. Dabei verwendet GraphQL ebenfalls die HTTP-Methoden. Allerdings können die Ausdrucksmöglichkeiten der HTTP-Semantik für einzelne Operationen verloren gehen. [3]

Abfragen erfolgen über so genannte Queries und Änderungen über Mutations im JSON Format.

Beispiel:

query{getPersons{name}}

Alle Queries und Mutations müssen in Form des Methodennamens und optional zusätzlicher Kommentare dokumentiert werden. Somit gibt es keine eindeutige Semantik. Es kann z.B. für die Methode Löschen unterschiedliche Präfixe wie delete oder remove in jeder API geben. Normalerweise wird der Request über eine POST-Methode an die API gesendet. Die Query befindet sich dann im Body. Der Request kann aber auch über eine GET-Methode erfolgen. In diesem Fall wird die Query als Parameter hinten an die URL gesetzt. [3]

Bei GraphQL können die Clients in den Queries genau festlegen, welche Information sie vom Server brauchen. Diese werden dann vom Server verarbeitet und es werden nur die angeforderten Informationen zurückgegeben. Dadurch können in der Regel alle Daten durch einen einzigen Request erreicht werden. Somit verhindert GraphQL in den meisten Fällen Over- und Underfetching. [3]

Ein denkbares Problem ist gegebenfalls die Tiefe der Knoten. Sollte ein Knoten nur über viele weitere Knoten erreichbar sein, so kann die Query an Suchtiefe und Komplexität gewinnen. Dies kann zu Problemen bei der Performance führen.

Auch wird das Schema der Daten größtenteils offen gelegt, da Queries vom Client nach diesem Schema erstellt werden müssen. Dies stellt ein klares Sicherheitsrisiko dar.

Einen Vorteil hat GraphQL bei der Versionierung. Im Server können problemlos neue Typen und Felder hinzugefügt werden. Der Client stellt gezielte Requests. Somit entstehen keine Probleme. Das Ändern und Löschen von bereits vorhandenen Typen und Feldern hingegen kann zu Problemen führen. Clients müssen hier ebenfalls angepasst werden. [8, S. 77-78]