GraphQL vs. REST-API

Hast du schon einmal an einem Web-App-Entwicklungsprojekt gearbeitet? Wenn ja, dann bist du möglicherweise bereits auf den Begriff "GraphQL" gestoßen. Aber was genau bedeutet das? Wird es in serverseitigen oder clientseitigen Konfigurationen verwendet? Außerdem, wann ist die Integration von GraphQL anderen Alternativen vorzuziehen? In diesem Artikel führen wir dich durch diese Fragen.

Als Kommunikationskanal für den Datentransfer zwischen Softwarekomponenten über das Internet spielen APIs eine unverzichtbare Rolle in modernen Web-Service-Architekturen und wirken wie Sauerstoff. API-Technologien wie SOAP (ein Webdienst-Messaging-Protokoll), REST (architektonischer Stil) und GraphQL (eine Abfragesprache und ein Tool) erleichtern die Softwareentwicklung, indem sie die Integration und den Datenaustausch zwischen verschiedenen Diensten unterstützen, was die Entwicklung bequemer und flexibler macht.

Trotz der zahlreichen Arten von APIs konzentrieren sich die Debatten der letzten Jahre hauptsächlich auf zwei Hauptparadigmen: REST (Representational State Transfer) und GraphQL. Beide bieten eine Reihe von Vorteilen und werden in Webprojekten weltweit genutzt. Sie unterscheiden sich jedoch erheblich in der Art und Weise, wie sie die Datenkommunikation verwalten.

Was ist eine REST-API?#

REST ist ein strukturierter Architekturstil, der im frühen 21. Jahrhundert für den Aufbau von hypermedienübergreifenden Anwendungen entwickelt wurde und darauf abzielt, ein zustandsloses, cachefähiges Kommunikationsprotokoll zwischen Clients und Servern zu übernehmen. Die REST-API (auch als RESTful-API bekannt) ist der Treiber der REST-Architektur.

REST-API verwendet Uniform Resource Identifiers (URIs) zur Adressierung von Ressourcen. REST-API arbeitet mit verschiedenen Endpunkten, um CRUD-Operationen (erstellen, lesen, aktualisieren und löschen) für Netzwerkressourcen durchzuführen. Sie stützt sich auf vordefinierte Datenformate (bekannt als Medientypen oder MIME-Typen), um die Form und Größe der Ressourcen zu bestimmen, die sie den Clients bereitstellen. Die häufigsten Formate sind JSON und XML (manchmal HTML oder Klartext).

Nachdem der Client eine Ressource angefordert hat, verarbeitet der Server die Anfrage und gibt alle Daten zurück, die sich auf diese Ressource beziehen. Die Antwort enthält HTTP-Statuscodes wie "200 OK" (für eine erfolgreiche REST-Anfrage) und "404 Not Found" (für eine nicht vorhandene Ressource).

Wie funktioniert die REST-API?#

REST-APIs basieren auf vordefinierten Endpunkten, die Ressourcen über HTTP bereitstellen. Jeder Endpunkt repräsentiert eine Ressource, wie etwa Benutzer oder Beiträge, und wird durch eine eindeutige URL identifiziert. REST-Operationen sind an standardisierte HTTP-Methoden wie GET, POST, PUT und DELETE gebunden, die dem Abrufen, Erstellen, Aktualisieren und Löschen von Daten entsprechen.

Zum Beispiel ruft eine Anfrage an GET /users eine vollständige Liste von Benutzern ab, während GET /users/123 die Details eines bestimmten Benutzers abholt, der durch seine ID identifiziert wird. Wenn du auch auf verwandte Daten zugreifen musst, wie z. B. die Organisationen des Benutzers und die jeweiligen Rollen in der Organisation, müsstest du zusätzliche Anfragen an GET /users/123/organizations stellen.

REST folgt einem ressourcenorientierten Ansatz, der sich auf den Zugriff und die Manipulation diskreter Ressourcen konzentriert.

Was ist GraphQL?#

GraphQL ist sowohl ein API-Typ (oder eine Abfragesprache) als auch eine Laufzeit-Engine zur Beantwortung dieser Abfragen. Es bietet eine vereinfachte API und ist besonders geeignet für mobile Anwendungen und die Implementierung komplexer Architekturen, die spezifische Datensubsets erfordern.

Mit GraphQL können Entwickler angeben, welche Daten sie von der API abrufen möchten. Es ermöglicht auch den Abruf von Daten auf Abruf, anstatt alles auf einmal abzurufen, nimmt Änderungen sofort vor und integriert Drittanbieter-Datenquellen in die Anwendung.

Anwendungen können GraphQL-Abfragen verwenden, um GraphQL-Dienste aufzurufen. Diese Abfragen liefern die genauen Datenelemente, die vom Client angefordert werden. Das spart mehrere API-Aufrufe, Netzwerkbandbreite und Nachbearbeitung. Es ist eine hocheffiziente Lösung für datenorientierte APIs, die sich in der Nähe von Verbrauchsgeräten wie Tablets und Mobiltelefonen befinden.

Wie funktioniert GraphQL?#

GraphQL verfolgt im Gegensatz dazu einen abfragebasierten Ansatz. Anstatt vordefinierte Endpunkte anzubieten, stellt GraphQL einen einzigen Endpunkt bereit, der strukturierte Abfragen akzeptiert. Clients spezifizieren genau, welche Daten sie mit einer Abfragesprache benötigen.

Daher muss eine vollständige GraphQL-Implementierung zwei Teile enthalten: Schema und Resolver.

GraphQL-Schema#

Schemas definieren die Datentypen und ihre Felder, die durch GraphQL-Abfragen abgerufen werden können:

Zum Beispiel hättest du folgendes Schema:

Ein Client kann den Namen, die E-Mail, die Organisationen und die Rollen eines Benutzers mit der folgenden Abfrage abfragen:

Diese Abfrage ruft nicht nur die angeforderten Felder (E-Mail und Organisationen) ab, sondern holt auch die zugehörigen Daten (Rollen) in einer einzigen Anfrage ab.

GraphQL-Resolver#

Ein GraphQL-Resolver ist ein Schlüsselbestandteil in einem GraphQL-Server, der bestimmt, wie die vom Kunden in einer GraphQL-Abfrage angeforderten Daten abgerufen oder berechnet werden. Wenn ein Kunde eine Abfrage sendet, wird jedes Feld in der Abfrage einem Resolver zugeordnet, der die Logik zum Abrufen oder Berechnen der Daten für dieses Feld enthält.

Im obigen Beispiel würden die Resolver für das Schema so aussehen:

Es gibt zwei Arten von Resolvern: Root-Resolver und Feld-Resolver.

• Root-Resolver: Bearbeiten die obersten Felder im Schema, wie Query, Mutation und Subscription.
• Feld-Resolver: Behandeln einzelne Felder innerhalb eines Typs, oft für verschachtelte Abfragen. Wenn kein spezifischer Resolver für ein Feld bereitgestellt wird, verwendet GraphQL den Standard-Resolver, der den Wert vom übergeordneten Objekt mit dem passenden Feldnamen zurückgibt.

GraphQL-Operationen#

GraphQL unterstützt drei Arten von Operationen: Abfragen, Mutationen und Subskriptionen.

• Query: Wird verwendet, um Daten zu LESEN.
• Mutation: Wird verwendet, um Daten zu SCHREIBEN, einschließlich Operationen zum Hinzufügen, Ändern und Löschen von Daten.
• Subscription: Wird verwendet, um eine dauerhafte Verbindung für Daten anzufordern, sodass der Client die Arten von Ereignissen erklären kann, an denen er interessiert ist und welche Daten zurückgegeben werden sollen.

Unterschiede zwischen GraphQL und REST-APIs#

GraphQL und REST-APIs sind Werkzeuge zum Austausch von Daten zwischen verschiedenen Webdiensten, aber aufgrund ihrer unterschiedlichen Ansätze zur Lösung von Problemen gibt es hier die wichtigsten Unterschiede zwischen ihnen:

Datenerfassung#

Die REST-API erfasst oft zu viele oder zu wenige Daten, da Endpunkte feste Antworten zurückgeben. GraphQL löst dieses Problem, indem es Clients ermöglicht, genau das anzufordern, was sie brauchen, wodurch unnötiger Datentransfer reduziert wird. Dies macht GraphQL ideal für Anwendungen mit komplexen Datenbedürfnissen, wie z. B. mobile oder geringere Bandbreitenumgebungen.

Stell dir das obige Beispiel vor, in dem du die statischen Daten eines Benutzers, Organisationen und die dem Benutzer zugewiesenen Organisationsrollen abrufen musst. Mit der REST-API müsstest du mehrere Anfragen an verschiedene Endpunkte stellen, um alle Daten zu erhalten. Mit GraphQL kannst du jedoch alle Daten in einem einzigen Anfrage bekommen.

Flexibilität#

Die endpunktbasierte Struktur von REST ist einfach und funktioniert gut für einfache Anwendungen mit standardisierten CRUD-Operationen. Dies liegt daran, dass REST-APIs ressourcenzentriert gestaltet sind, wobei jeder Endpunkt eine spezifische Ressource darstellt. Die größte Einschränkung dieses Ansatzes besteht darin, dass er keine schnelle Iteration und Änderungen der Client-Anforderungen ermöglicht. Mit jeder Änderung, die am Client vorgenommen wird, muss der Server aktualisiert werden, um den neuen Anforderungen gerecht zu werden, entweder durch Hinzufügen neuer Endpunkte oder Aktualisieren bestehender. Dies führt oft zu vielen redundanten Endpunkten und einem komplexen API-Versionsmanagement.

GraphQL hingegen ist flexibler und ermöglicht es Clients, nur die Daten anzufordern, die sie benötigen. Diese Flexibilität ist besonders nützlich, wenn sich die Anforderungen der Clients häufig ändern, da sie keine Änderungen an der serverseitigen API-Implementierung erfordert. Clients können neue Felder oder verschachtelte Daten anfordern, ohne Änderungen am Server vorzunehmen.

Caching#

Auch wenn GraphQL in Bezug auf die Datenerfassung effizienter und flexibler ist, hat es auch einige Nachteile. Eine der Hauptprobleme ist das Caching.

Die REST-API verfügt über ein ausgereiftes Ökosystem. Aufgrund ihrer zustandslosen und standardisierten Natur ist es einfach, Antworten sowohl auf Server- als auch auf Clientebene zwischenzuspeichern. Dies kann die Anzahl der Anfragen an den Server erheblich reduzieren und die Leistung verbessern.

Aufgrund ihrer Flexibilität sind jedoch viele der für die REST-API verfügbaren Caching-Technologien nicht auf GraphQL anwendbar. Es ist notwendig, das Caching auf der Clientseite basierend auf spezifischen Anwendungsfällen zu verwalten, was zusätzliche Arbeit für die Cliententwicklung bedeutet.

Vor- und Nachteile#

Fazit#

Obwohl GraphQL in den letzten Jahren als Neuling an Fahrt gewonnen hat, behält die REST-API aufgrund ihres atomaren Designs und ihrer Strenge weiterhin eine große Bedeutung.

REST und GraphQL erfüllen unterschiedliche Bedürfnisse und sind in unterschiedlichen Szenarien hervorzuheben. Die Einfachheit von REST macht es zu einer perfekten Wahl für einfache Anwendungen und Microservices. GraphQL zeichnet sich in Szenarien aus, die flexible und effiziente Datenerfassung erfordern, insbesondere in Anwendungen mit unterschiedlichen Clients oder komplexen Beziehungen zwischen Daten. Die Wahl zwischen den beiden hängt von den spezifischen Anforderungen deines Projekts, dem Fachwissen des Teams und den langfristigen Skalierbarkeitsbedürfnissen ab.