GraphQL vs. REST API: Was ist der Unterschied?

Als Kanäle, über die Softwarekomponenten interagieren und Daten über das Internet fließen, sind APIs das Lebenselixier moderner Webdienste. API-Technologien wie SOAP (ein Web-Services-Messaging-Protokoll), REST (ein Architekturstil) und GraphQL (eine Programmiersprache und ein Tool) vereinfachen die Softwareentwicklung, indem sie die Integration von Daten und Diensten von Drittanbietern ermöglichen. APIs ermöglichen es Unternehmen auch, Mitarbeitern, Geschäftspartnern und Benutzern sichere Servicefunktionen und den Datenaustausch anzubieten.

Ungeachtet der vielen Arten von APIs wurden in den letzten zwei Jahren vor allem zwei große Paradigmen debattiert: REST (Representational State Transfer) und GraphQL. Beide bieten eine Reihe von Vorteilen und werden daher für Netzwerkprojekte auf der ganzen Welt eingesetzt. In der Art und Weise, wie sie den Datenverkehr verwalten, unterscheiden sie sich jedoch erheblich. Im Folgenden analysieren wir diese Unterschiede und erörtern, wie Unternehmen REST- und GraphQL-APIs zur Optimierung ihrer Netzwerke nutzen können.

Für einen Vergleich der beiden APIs ist ein individuelles Verständnis von REST- und GraphQL-APIs erforderlich.

REST

REST wurde Anfang der 2000er Jahre entwickelt und ist ein strukturierter Architekturstil für vernetzte Hypermedia-Anwendungen, der darauf ausgelegt ist, ein zustandsloses, zwischenspeicherfähiges Client/Server-Kommunikationsprotokoll zu verwenden. REST-APIs, auch RESTful APIs genannt, sind die Treiber von REST-Architekturen.

REST-APIs verwenden eindeutige Ressourcenkennungen (Unique Resource Identifiers, URIs), um Ressourcen zu adressieren. REST-APIs arbeiten so, dass verschiedene Endpunkte CRUD-Operationen („Create“, „Read“, „Update“ und „Delete“) für Netzwerkressourcen ausführen. Sie verlassen sich auf ein vordefiniertes Datenformat – einen sogenannten Medientyp oder MIME-Typ –, um die Form und Größe der Ressourcen zu bestimmen, die sie ihren Kunden zur Verfügung stellen. Die gängigsten Formate sind JSON und XML (und manchmal auch HTML oder einfacher Text).

Wenn der Client eine Ressource anfordert, verarbeitet der Server die Abfrage und gibt alle Daten zurück, die mit dieser Ressource verknüpft sind. Die Antwort enthält HTTP-Antwortcodes wie „200 OK“ (für erfolgreiche REST-Anfragen) und „404 Not Found“ (für nicht vorhandene Ressourcen).

GraphQL

GraphQL ist eine Abfragesprache und API-Laufzeit, die Facebook 2012 intern entwickelt hat, bevor sie 2015 Open Source wurde.

GraphQL wird durch ein API-Schema definiert, das in der GraphQL-Schemadefinitionssprache geschrieben wurde. Jedes Schema gibt die Datentypen an, die der Benutzer abfragen oder ändern kann, sowie die Beziehungen zwischen den Typen. Ein Resolver unterstützt jedes Feld in einem Schema. Der Resolver bietet Anweisungen zum Umwandeln von GraphQL-Abfragen, -Mutationen und -Abonnements in Daten und ruft Daten aus Datenbanken, Cloud-Diensten und anderen Quellen ab. Resolver stellen außerdem Spezifikationen für das Datenformat bereit und ermöglichen es dem System, Daten aus verschiedenen Quellen zusammenzuführen.

Im Gegensatz zu REST, das in der Regel mehrere Endgeräte verwendet, um Daten abzurufen und Netzwerkoperationen durchzuführen, legt GraphQL Datenmodelle offen, indem es ein einziges Endgerät verwendet, über das Clients GraphQL-Anfragen senden, unabhängig davon, wonach sie fragen. Die API greift dann auf die Ressourceneigenschaften zu und folgt den Verweisen zwischen den einzelnen Ressourcen, um dem Client alle benötigten Daten mit einer einzigen Abfrage an den GraphQL-Server zu übermitteln.

Sowohl GraphQL- als auch REST-APIs sind ressourcenbasierte Datenaustauschsysteme, die HTTP-Methoden (wie PUT- und GET-Anfragen) verwenden, die vorgeben, welche Vorgänge ein Client ausführen kann. Es gibt jedoch wesentliche Unterschiede zwischen ihnen, die nicht nur die Verbreitung von GraphQL erklären, sondern auch, warum RESTful-Systeme so langlebig sind.

GraphQL bietet eine effiziente, flexiblere Ergänzung zu REST. GraphQL-APIs werden oft als Upgrade von RESTful-Umgebungen angesehen, insbesondere aufgrund ihrer Fähigkeit, die Zusammenarbeit zwischen Front-End- und Back-End-Teams zu erleichtern. GraphQL ist ein logischer nächster Schritt auf dem Weg einer Organisation zur API und hilft bei der Behebung von Problemen, die häufig bei REST auftreten.

REST war jedoch lange Zeit Standard für API-Architekturen, und viele Entwickler und Architekten verlassen sich immer noch auf RESTful-Konfigurationen, um ihre IT-Netzwerke zu verwalten. Daher ist das Verständnis der Unterschiede zwischen beiden ein wesentlicher Bestandteil der IT-Managementstrategie jeder Organisation.

REST- und GraphQL-APIs unterscheiden sich in der Art und Weise, wie sie Folgendes verwalten:

Abrufen von Daten

Da REST auf mehreren Endpunkten und zustandslosen Interaktionen beruht – bei denen jede API-Anforderung als neue Abfrage unabhängig von anderen verarbeitet wird – erhalten die Clients alle Daten, die mit einer Ressource verknüpft sind. Auch wenn ein Client nur eine Teilmenge der Daten benötigt, erhält er trotzdem alle Daten (Überabruf). Und wenn der Client Daten benötigt, die sich über mehrere Ressourcen erstrecken, lässt ein RESTful-System den Client oft jede Ressource separat abfragen, um die unzureichende Datenabfrage von der ursprünglichen Anfrage zu kompensieren (Unterabruf). GraphQL-APIs verwenden einen einzelnen GraphQL-Endpunkt, um Kunden eine präzise, umfassende Datenantwort in einem einzigen Roundtrip aus einer einzigen Anfrage zu bieten und so Probleme mit übermäßigem und zu geringem Abruf zu vermeiden.

Versionierung

In einer REST-Architektur müssen Teams APIs versionieren, um Datenstrukturen zu ändern und Systemfehler und Dienstunterbrechungen für den Endbenutzer zu verhindern. Mit anderen Worten: Entwickler müssen bei jeder Änderung einen neuen Endpunkt erstellen, wodurch mehrere API-Versionen entstehen und die Wartung möglicherweise erschwert wird. GraphQL reduziert den Bedarf an Versionierung, da Clients ihre Anforderungen in der Abfrage angeben können. Das Hinzufügen neuer Felder zum Server hat keine Auswirkungen auf Clients, die diese Felder nicht benötigen. Umgekehrt können Clients veraltete Felder weiterhin abfragen, bis die Abfragen aktualisiert werden.

Fehlerbehandlung

REST-APIs sollten HTTP-Statuscodes verwenden, um den Status oder den Erfolg einer Anforderung anzugeben, und jeder Statuscode hat eine bestimmte Bedeutung. Eine erfolgreiche HTTP-Anfrage gibt den Statuscode 200 zurück, während ein Client-Fehler den Statuscode 400 und ein Server-Fehler den Statuscode 500 zurückgeben kann.

Auf den ersten Blick scheint dieser Ansatz zur Statusberichterstattung einfacher zu sein, aber HTTP-Statuscodes sind für Webbenutzer oft nützlicher als für die APIs selbst, insbesondere im Falle von Fehlern. REST verfügt nicht über eine Spezifikation für Fehler, sodass API-Fehler eventuell als Transportfehler oder ganz ohne Statuscode angezeigt werden. In einem solchen Fall müssen Mitarbeitende die Statusdokumentation durchlesen, um erkennen zu können, was Fehler bedeuten oder wie Fehler innerhalb der Infrastruktur kommuniziert werden.

Bei GraphQL-APIs gibt jede Anfrage – unabhängig davon, ob sie zu einem Fehler geführt hat – den Statuscode 200 OK zurück, da Fehler nicht mithilfe von HTTP-Statuscodes übermittelt werden (außer bei Transportfehlern). Stattdessen teilt das System Fehler im Antwortkörper zusammen mit den Daten mit, so dass die Clients die Daten-Nutzlast analysieren müssen, um festzustellen, ob die Anfrage erfolgreich war.

Allerdings verfügt GraphQL über eine Spezifikation für Fehler, sodass API-Fehler leichter von Transportfehlern unterschieden werden können. Die genaue Art der Fehler wird im Eintrag „errors“ (Fehler) im Antworttext angezeigt, was dazu führen kann, dass bevorzugt mit GraphQL-APIs gearbeitet wird.

Echtzeitdaten

REST bietet keine integrierte Unterstützung für Echtzeit-Updates. Wenn eine App Echtzeitfunktionen benötigt, müssen Entwickler in der Regel Techniken wie Long-Polling (bei dem der Client den Server wiederholt nach neuen Daten abfragt) und vom Server gesendete Ereignisse implementieren, was die Anwendung komplexer machen kann.

GraphQL bietet dagegen integrierte Unterstützung für Echtzeit-Updates mithilfe von Abonnements. Abonnements halten eine stabile Verbindung zum Server aufrecht, sodass der Server bei bestimmten Ereignissen Aktualisierungen an den Client weiterleiten kann.

Tools und Umgebung

Das REST-Umfeld ist gut etabliert und bietet Entwicklern eine breite Palette an Tools, Bibliotheken und Frameworks. Bei der Arbeit mit REST-APIs müssen Teams jedoch durch mehrere Endpunkte navigieren und die einzigartigen Konventionen und Muster jeder API verstehen.

GraphQL-APIs sind relativ neu, aber die GraphQL-Umgebung ist seit ihrer Einführung enorm gewachsen, mit verschiedenen Tools und Bibliotheken, die sowohl für die Serverseite als auch für die Clientseite verfügbar sind. Tools wie GraphiQL und GraphQL Playground bieten leistungsstarke, im Browser integrierte Entwicklungsumgebungen (IDEs) zum Erkunden und Testen von GraphQL-APIs. Darüber hinaus bietet GraphQL eine starke Unterstützung für die Codegenerierung, was die Entwicklung auf der Clientseite vereinfachen kann.

Caching

REST-APIs basieren auf Mechanismen wie eTags und zuletzt geänderten Headern, um API-Aufrufe zwischenzuspeichern. Diese Caching-Strategien sind zwar effektiv, aber eventuell umständlich zu implementieren und möglicherweise nicht für alle Anwendungsfälle geeignet.

Das Zwischenspeichern von GraphQL-APIs kann aufgrund der dynamischen Natur der Abfragen schwieriger sein. Durch die Bereitstellung persistenter Abfragen, Antwort-Caching und serverseitiges Caching können diese Herausforderungen jedoch gemildert und die Caching-Bemühungen in GraphQL-Architekturen optimiert werden.

Weder REST- noch GraphQL-APIs sind von Natur aus überlegen; es sind unterschiedliche Tools, die für unterschiedliche Aufgaben geeignet sind.

REST ist im Allgemeinen einfacher zu implementieren und kann eine gute Wahl sein, wenn ein einfaches, zwischenspeicherbares Kommunikationsprotokoll mit strengen Zugriffskontrollen bevorzugt wird (z. B. für öffentlich zugängliche E-Commerce-Websites wie Shopify und GitHub). Angesichts des Risikos eines zu niedrigen oder zu hohen Abrufs eignen sich REST-APIs am besten für:

• Unternehmen, die kleinere Apps mit einfacheren Datenprofilen verwenden
• Unternehmen ohne komplexe Anforderungen an die Datenabfrage
• Unternehmen, in denen die meisten Kunden Daten und Vorgänge auf ähnliche Weise nutzen

GraphQL-APIs ermöglichen einen flexibleren, effizienteren Datenabruf, der die Systemleistung und die Benutzerfreundlichkeit für Entwickler verbessern kann. Diese Funktionen machen GraphQL besonders nützlich für die Erstellung von APIs in komplexen Umgebungen mit sich schnell ändernden Front-End-Anforderungen. Dazu gehören:

• Unternehmen mit begrenzter Bandbreite, die Anfragen und Antworten begrenzen möchten
• Unternehmen, die Datenpunkte an einem Endpunkt kombinieren möchten
• Unternehmen, deren Kundenanfragen stark variieren

Obwohl sie unterschiedliche Ansätze verwenden, haben sowohl GraphQL als auch REST-APIs das Potenzial, die Skalierbarkeit des Netzwerks und die Serverleistung erheblich zu verbessern.

Unabhängig davon, ob Sie sich für die Bereitstellung von REST- oder GraphQL-APIs – oder eine Kombination aus beidem – entscheiden, kann Ihr Unternehmen von einer breiten Palette potenzieller Anwendungen profitieren, darunter Implementierungen in verschiedenen Programmiersprachen (wie JavaScript) und der Integration mit Microservices und serverlosen Architekturen. Mit IBM API Connect können Sie beide API-Typen verwenden, um Ihre IT-Infrastruktur zu optimieren.

IBM API Connect ist eine API-Managementlösung für den gesamten Lebenszyklus, die Sie bei der Erstellung, Verwaltung, Sicherung, Vernetzung und Monetarisierung von APIs unterstützt und die digitale Transformation in Rechenzentren und Cloud-Umgebungen fördert. Damit können sowohl Unternehmen als auch Kunden digitale Apps nutzen und Innovationen in Echtzeit fördern.

Mit API Connect können Unternehmen sicherstellen, dass sie beim API-Management auf dem neuesten Stand sind. Dies wird sich in einer IT-Umgebung, die im Laufe der Zeit immer größer, komplexer und wettbewerbsintensiver werden wird, als unschätzbar wertvoll erweisen.