GraphQL vs REST: Wie sie sich wirklich unterscheiden
GraphQL vs REST
GraphQL vs REST: dieselben Daten auf beide Arten abgerufen | We.Inc
Vergleiche GraphQL und REST anhand derselben Daten, auf beide Arten abgerufen: Anzahl der Requests, Over-Fetching, Caching, Fehlerrückgabe und eine Tabelle für die Entscheidung.
REST stellt viele URLs bereit, eine pro Ressource, und der Server entscheidet, was jede Antwort enthält. GraphQL stellt einen einzigen Endpoint bereit, meist /graphql, an den der Client eine Query schickt, die genau die gewünschten Felder nennt. REST bekommt HTTP-Caching über die URL gratis; GraphQL spart Roundtrips und lässt ungenutzte Felder weg, auf Kosten von mehr Arbeit auf dem Server.
Auf einen Blick
Thema
REST
GraphQL
Endpoints
Eine URL pro Ressource
Ein Endpoint, oft /graphql
Wer die Felder wählt
Der Server
Der Client, in der Query
Verknüpfte Daten
Oft mehrere Requests
Verschachtelt in einer Query
HTTP-Caching
Eingebaut für GET per URL
Braucht GET-Queries, Persisted Queries oder einen Client-Cache
Fehler
Meist HTTP-Statuscodes
Ein errors-Array, oft neben Teildaten
Schema
Optional (OpenAPI)
Pflicht und typisiert
Der Vergleich unten ruft denselben Bildschirm voller Daten auf beide Arten ab. Wähle ein Szenario, um die REST-Aufrufe eines Clients neben der einen GraphQL-Query zu sehen, die sie ersetzt, und was jede Antwort weglässt oder zusätzlich mitliefert.
Wähle ein Szenario, etwa eine Profilseite mit den neuesten Beiträgen.
Lies links die REST-Requests und rechts die GraphQL-Query.
Vergleiche die Anzahl der Requests unter den Feldern.
Lies den Hinweis, um zu sehen, wo jeder Stil mehr Daten sendet, als der Bildschirm braucht.
Stell eine funktionierende REST-API nicht nur aus Mode auf GraphQL um. Der Vorteil zeigt sich, wenn viele verschiedene Screens unterschiedliche Ausschnitte verknüpfter Daten brauchen.
Stelle auf jedem GraphQL-Typ ein stabiles id-Feld bereit, damit Client-Bibliotheken ihren Cache danach normalisieren können.
Prüfe das errors-Array bei jeder GraphQL-Antwort, auch wenn der Status 200 ist und Daten vorhanden sind.
Setze Tiefen- und Kostenlimits für einen öffentlichen GraphQL-Endpoint, denn eine einzige verschachtelte Query kann sehr viel Arbeit anfordern.
Häufige Fragen
Ist GraphQL schneller als REST?
Nicht von allein. Es kann Roundtrips und Payload-Größe für Screens reduzieren, die verknüpfte Daten brauchen, aber jede Query kann den Server beim Auflösen mehr kosten. Ein gut gestalteter REST-Endpoint für einen Screen kann genauso schnell sein.
Warum kommt ein GraphQL-Fehler mit Status 200 zurück?
Ein Feld kann scheitern, während andere gelingen, daher gibt der Server die vorhandenen Daten plus ein errors-Array zurück. Die Empfehlungen für GraphQL over HTTP nutzen 2xx für Teilerfolg; Server, die mit application/graphql-response+json antworten, nutzen 400, wenn ein Request die Validierung nicht besteht.
Können GraphQL-Antworten von einem CDN gecacht werden?
Ja, wenn Queries per GET gesendet werden, was Server nur für Queries erlauben dürfen. Lange Queries können URL-Limits überschreiten, daher nutzen Teams Persisted Queries, die einen kurzen Hash statt des ganzen Dokuments senden.
Kann ich beides in einem Produkt verwenden?
Viele Teams tun das. Datei-Uploads, Webhooks und einfache öffentliche Ressourcen bleiben oft REST-Routen, während App-Screens über eine GraphQL-Schicht lesen, die darunter dieselben Services aufrufen kann.
Braucht GraphQL eine eigene Datenbank?
Nein. Ein GraphQL-Server ist eine Schicht aus Resolvern, kleinen Funktionen, die jedes Feld dort abrufen, wo die Daten liegen: in einer Datenbank, einem REST-Service oder einer Datei. Das Schema beschreibt Formen, keine Speicherung.
Over-Fetching und Under-Fetching
Ein REST-Endpoint liefert eine feste Form. Ein Listen-Screen, der nur Namen zeigt, lädt trotzdem jedes Feld jedes Nutzers herunter, das ist Over-Fetching. Ein Detail-Screen, der einen Nutzer plus seine Beiträge plus die Kommentaranzahl jedes Beitrags braucht, benötigt eventuell mehrere Aufrufe, das ist Under-Fetching.
GraphQL verlagert diese Entscheidung zum Client. Die Query listet die Felder auf, der Server liefert genau diese Form und nichts sonst. Der Preis dafür: Der Server muss jede Feldkombination verarbeiten, die ein Client anfragen könnte.
Caching funktioniert anders
Bei REST ist eine URL ein Cache-Schlüssel. Browser und CDNs können eine GET-Antwort speichern und wiederverwenden, weil GET und HEAD die cachebaren Methoden sind. Der meiste GraphQL-Traffic ist POST an eine URL, was diese Caches nicht speichern.
GraphQL-Clients gleichen das in der App aus: Sie zerlegen Antworten in Objekte und speichern sie nach id, sodass zwei Queries, die denselben Nutzer betreffen, sich einen gecachten Datensatz teilen. graphql.org empfiehlt genau aus diesem Grund ein global eindeutiges id-Feld.
Fehler und Statuscodes
REST stützt sich auf die Statuszeile: 404 für einen fehlenden Datensatz, 401 ohne Anmeldung, 422 für ungültige Eingaben. Clients können allein anhand des Codes verzweigen.
Eine GraphQL-Antwort hat einen data-Schlüssel, einen errors-Schlüssel oder beides. Ein Syntax- oder Validierungsproblem ergibt errors und keine Daten. Ein Fehler in einem einzelnen Feld ergibt Teildaten, bei denen dieses Feld null ist, und einen Fehlereintrag, dessen path darauf zeigt.
Was du wählen solltest
Entscheidungstabelle
Deine Situation
Tendiert zu
Öffentliche API, die Dritte mit curl aufrufen
REST
Viele Screens, die jeweils andere verknüpfte Daten brauchen
GraphQL
Starkes CDN-Caching von Lesezugriffen
REST oder GraphQL mit Persisted GET Queries
Mobile Clients in langsamen Netzen
GraphQL, weniger Roundtrips
Einfaches CRUD über wenige Tabellen
REST
Mehrere Backend-Services hinter einem gemeinsamen Eingang
GraphQL als Gateway-Schicht
Was über die Leitung geht
Ein GraphQL-Request mit fetch
Jede Operation ist ein POST von JSON mit den Schlüsseln query und variables an den einen Endpoint. Der Accept-Header fordert den neueren GraphQL-Antworttyp an, mit einfachem JSON als Fallback.
Eine GraphQL-Teilantwort
Ein Feld ist fehlgeschlagen, daher ist es null, und der errors-Eintrag benennt es mit path. Die restlichen Daten sind trotzdem angekommen.
Profil mit Beiträgen
REST braucht einen zweiten Aufruf für die Beiträge, und beide Antworten enthalten jedes Feld, das der Server mitliefert. Die GraphQL-Query gibt nur Name, Avatar und drei Beitragstitel zurück.
Nur Namen
Für eine einfache Liste ist der REST-Aufruf so oder so ein Request, aber er sendet ganze Nutzerdatensätze. GraphQL sendet nur die zwei angefragten Felder.
Beitrag mit Kommentaren und Autoren
Ohne eigenen Endpoint durchläuft REST den Baum eine Ebene pro Request, und das Abrufen jedes Kommentarautors kann einen weiteren Aufruf pro Kommentar bedeuten. GraphQL verschachtelt den ganzen Baum in einer Query.
Einen Beitrag erstellen
Schreibvorgänge sehen ähnlich aus: jeweils ein Request. REST nutzt die POST-Methode auf einer Collection-URL; GraphQL sendet eine Mutation, ebenfalls als HTTP-POST, und wählt, welche Felder des neuen Beitrags zurückkommen.