GraphQL vs REST

Wir können GraphQL nur mit REST vergleichen, wenn wir zuerst über APIs sprechen. Die Anwendungsprogrammierschnittstelle (API) ist der Grundbaustein moderner netzwerkbasierter Anwendungen. Ob Sie nun Web- oder native Anwendungen, Microservices oder IoT-Lösungen entwickeln, in vielen Fällen müssen wir Daten zwischen Softwaresystemen über APIs austauschen. Darüber hinaus hat die zunehmende Einführung der Hybrid-Cloud dazu geführt, dass Daten in unterschiedlichen Datenbanken gespeichert werden, manchmal über verschiedene Clouds und On-Premises-Umgebungen hinweg. APIs dienen als wichtiges Bindeglied zwischen Datenquellen und Anwendungen.

Beim Entwurf einer API für das Web tauchen Begriffe wie GraphQL, REST, SOAP und rPC auf. Wie können Teams also entscheiden, welchen Architekturstil oder welches Protokoll sie bei ihrer API-Entwicklung verwenden sollten? Obwohl alle genannten Ansätze ihre Berechtigung haben, konzentrieren wir uns in diesem Artikel nur auf GraphQL vs. REST.

GraphQL vs. REST: Eine Einführung in REST

REST (Representational State Transfer) ist ein beliebter architektonischer Stil zum Aufbau von Webdiensten oder APIs. Er wurde erstmals in einer Dissertation von Roy Fielding vorgestellt, in der er beschreibt, wie der REST-Stil bei der Skalierbarkeit von netzwerk-basierten Systemen helfen kann.

Prinzipien und Einschränkungen, die eine RESTful API erfüllen muss:

• Entkopplung: Dienstanforderer, genannt Clients (Frontend), und Dienstanbieter, genannt Server (Backend), können nur über Endpunkte kommunizieren.

• Einheitlichkeit: Endpunkte sollten geräteübergreifend dieselbe Schnittstelle haben, um die Wiederverwendbarkeit zu fördern und die unabhängige Entwicklungsfähigkeit von Komponenten zu unterstützen.

• Zustandslosigkeit: Auf der Serverkomponente ist kein Sitzungsstatus erlaubt, um die Zuverlässigkeit und Skalierbarkeit zu verbessern. Jede Anfrage eines Clients muss alle Informationen enthalten, die für die Bearbeitung erforderlich sind.

• Idempotenz: Eine Anfrage kann mehrfach ausgeführt werden, ohne dass sich das Ergebnis über die erste Anwendung hinaus ändert.

RESTful-APIs sind in der Regel leichtgewichtig, skalierbar und schnell, was sie ideal für die Erstellung einer Vielzahl von Web- und Mobilanwendungen macht. REST-APIs verwenden HTTP-Methoden wie GET, POST, PUT und DELETE, um Operationen mit Ressourcen durchzuführen, die normalerweise eine feste Datenstruktur zurückgeben.

Da es sich bei REST nicht um einen Standard handelt, haben Tausende von Entwicklern unterschiedliche Interpretationen dessen, was REST bedeutet. Und genau das ist ein Teil des Problems. Es gibt viele unterschiedlich strukturierte REST-APIs.

Arbeiten mit REST-APIs

Bei REST besteht eine Anfrage aus einer HTTP-Methode, die für eine Ressource durchgeführt wird, die durch einen Uniform Resource Identifier (URI) dargestellt wird. Die vier primären Funktionen, Erstellen, Lesen, Aktualisieren und Löschen (CRUD), werden mit den folgenden HTTP-Verben ausgeführt

• HTTP POST (Erstellen): Übermittlung einer Entität durch den POST-Body, in erster Linie zur Erstellung einer Ressource auf dem Server.

• HTTP GET (Lesen): Anfordern von Ressourcen über ihre spezifischen Endpunkte.

• HTTP PATCH (Aktualisieren): Änderungen einer Ressource.

• HTTP DELETE (Löschen): Löschen einer Ressource.

Viele API-Entwickler verwenden die HTTP PUT-Methode, um Ressourcen teilweise zu aktualisieren. Die empfohlene Verwendung besteht darin, eine vorhandene Ressource durch die Anfrage zu ersetzen.

Als Teil der Anfrage können der Client und der Server zusätzliche Informationen durch sogenannte HTTP-Header übergeben. Weitere Informationen zu HTTP-Headern finden Sie in der Entwicklerdokumentation von Mozilla (EN).

GraphQL vs. REST: Eine Einführung in GraphQL

GraphQL ist ein neuer Ansatz, um über APIs nachzudenken. Anstatt mit mehreren und sehr starren, vom Server definierten Endpunkten zu arbeiten, arbeitet GraphQL mit einem einzigen Endpunkt, um vorhandene Daten mithilfe von Abfragen abzurufen und Daten mithilfe von Mutationen zu ändern. Bei GraphQL definiert der Client durch seine intuitive Abfragesprache, mit welchen Feldern der Server antworten soll.

Die starke Typisierung ist ein weiterer entscheidender Vorteil, den GraphQL-APIs gegenüber klassischen RESTful-APIs haben. Der GraphQL-Server validiert und erzwingt die Struktur von Abfragen, Mutationen und Abonnements anhand des GraphQL-Schemas, bevor er sie ausführt.

Das starke Typsystem in GraphQL besteht aus den folgenden Elementen:

• Objekttypen

• Objektfelder

• Die Query-, Mutation- und Subscription-Root-Typen

• Enum-Typen

• Interfaces

• Eingabe-Typen

• Union-Typen

GraphQL-Abfragen sind das Äquivalent zu HTTP-GET-Anfragen in einer REST-API. GraphQL-Mutationen sind das Äquivalent zu HTTP POST-, PUT-, PATCH- und DELETE-Anfragen in einer REST-API. Wie bei REST-APIs können die Clients und Server zusätzliche Informationen über die HTTP-Header weitergeben. Außerdem kann ein GraphQL-API-Entwickler Subscriptions verwenden, um Echtzeit-Updates vom Server zu erhalten.

Mehr Infos zu GraphQL gibt es im Artikel Was ist GraphQL?

GraphQL vs. REST-Vergleich

Zunächst einmal geht es bei GraphQL und REST-APIs um das Senden von HTTP-Anfragen und den Empfang von Ergebnissen, die in der Regel in JSON formatiert sind, und GraphQL nutzt viele Elemente des REST-Modells. Der Hauptunterschied zwischen GraphQL und REST-APIs besteht jedoch darin, dass GraphQL (Graph Query Language) das Senden von Queries oder Mutationen über einen einzigen Endpunkt ermöglicht, im Gegensatz zu Ressourcen-spezifischen Endpunkten in REST-APIs.

Bei REST definieren die Endpunkte (Ressourcen) die Struktur der API, und die Validierung von Dateneingaben hängt von der Sorgfalt der Entwickler ab, die die serverseitige Funktionalität implementieren. Auch was die REST-API als Antwort liefert, liegt ganz in der Kreativität des API-Entwicklers. Wenn die Nutzer einer RESTful-API einen Endpunkt aufrufen, sind sie daher auf eine vollständige Dokumentation angewiesen. Die OpenAPI-Initiative hilft mit ihrer Spezifikation, die Discoverability von REST-Webdiensten zu verbessern.

Im Gegensatz dazu kann GraphQL, das stark typisiert ist, anhand eines Schemas validiert werden, das in der sprachunabhängigen GraphQL-Schemasprache definiert ist. Außerdem kann der Client die Daten anfordern, die er benötigt, und der Server gibt nur diese Daten zurück, was mehr Flexibilität und eine effizientere Datenübertragung ermöglicht.

GraphQL verbirgt die Komplexität von hybriden Cloud-Systemen mit mehreren Datenquellen oder APIs von Drittanbietern, indem es die Deklaration eines APIs von seiner Implementierung entkoppelt. Dieses leistungsfähige Konzept ermöglicht es Entwicklern, sogenannte Resolver an objektartige Felder anzuhängen, um Daten aus verschiedenen Quellen gleichzeitig abzurufen. Darüber hinaus können Clients Abfragen stapeln, um Ergebnisse für mehrere Objekttypen in einer einzigen HTTP-Anfrage abzurufen.

Eine Zusammenfassung einiger wichtiger Unterschiede, die Entwickler kennen sollten, finden Sie in der folgenden Tabelle.

ThemaGraphQLRESTGeneralSpezifikation und AbfragespracheArchitekturstilResource IdentitätEntkoppelt von der AbfrageEntpricht der AbfrageContent Typ(en)JSONJSON, XML, HTML, Text, u.a.IntrospektionEnthält IntrospektionsabfrageMuss zusätzlich implementiert werdenEndpunkteEin Endpunkt. Überlicherweise /graphqlPro Resource mehrere EndpunkteHTTP CachingWird nicht unterstütztWird unterstütztHTTP MethodenPOST, GETPOST, GET, PATCH, PUT, DELETEAntwortstrukturWird Client-seitig definiertWird Server-seitig definiertTypsystemStark typisiertSchwach typisiertVersionierungErlaubt Deprekation von FeldernÜber Versionierungsendpunkte

GraphQL vs. REST: Zusammenfassung

GraphQL hat in den letzten Jahren rasant an Popularität gewonnen, und Tech-Unternehmen wie Github, Shopify, Stripe und Twitter nutzen GraphQL bereits. Gartner® sagte voraus, dass bis 2025 mehr als 50 Prozent der Unternehmen GraphQL in der Produktion einsetzen werden, während es 2021 noch weniger als 10 Prozent waren.

GraphQL bietet ein starkes Typensystem, erfordert nur die Integration eines einzigen Endpunkts und reduziert unnötigen Datenverkehr erheblich, wodurch es für Anwendungsentwickler einfacher zu verwenden ist. Darüber hinaus vereinfacht es das Abrufen von Daten aus verschiedenen Quellen in einer einzigen Abfrage. Mit all diesen Vorteilen ist GraphQL die bessere Alternative zu REST-APIs.

Doch während GraphQL-APIs für Anwendungsentwickler einfacher zu integrieren sind, können sie für die Teams, die mit ihrer Erstellung beauftragt sind, eine Herausforderung darstellen. Unsere Aufgabe bei graphapi® ist es, Teams zu befähigen, mit Hilfe unseres No-Code-Backend-Builders schneller zu entwickeln. Egal, ob Sie Frontend-, Backend- oder Citizen-Entwickler sind, Sie können einen vollständig verwalteten GraphQL-Server einschließlich einer hoch skalierbaren Datenbank in wenigen Minuten bereitstellen.

Useful References

• Was ist GraphQL?
• Die GraphQL Query
• GraphQL Server
• Der GraphQL Playground
• GraphQL Tools
• Dissertation über REST von Roy Fielding
• GraphQL Spezifikation
• OpenAPI Spezifikation
• GraphQL Typegenerierung