GraphQL vs REST: dezelfde data op beide manieren opgehaald | We.Inc
Vergelijk GraphQL en REST met dezelfde data op beide manieren opgehaald: aantal requests, over-fetching, caching, hoe fouten terugkomen, en een tabel om te kiezen.
REST biedt veel URL's, één per resource, en de server bepaalt wat elke response bevat. GraphQL biedt één endpoint, meestal /graphql, waar de client een query stuurt die precies de gewenste fields noemt. REST krijgt gratis HTTP-caching per URL; GraphQL bespaart round trips en laat ongebruikte fields weg, ten koste van meer werk op de server.
In één oogopslag
Onderwerp
REST
GraphQL
Endpoints
Eén URL per resource
Eén endpoint, vaak /graphql
Wie kiest de fields
De server
De client, in de query
Gerelateerde data
Vaak meerdere requests
Genest in één query
HTTP-caching
Ingebouwd voor GET per URL
Vereist GET-queries, persisted queries of een clientcache
Fouten
Vooral HTTP-statuscodes
Een errors-array, vaak naast gedeeltelijke data
Schema
Optioneel (OpenAPI)
Verplicht en getypeerd
De vergelijking hieronder haalt hetzelfde scherm met data op beide manieren op. Kies een scenario om de REST-calls die een client zou doen te zien naast de ene GraphQL-query die ze vervangt, en wat elke response weglaat of toevoegt.
Kies een scenario, zoals een profielpagina met recente posts.
Lees de REST-requests links en de GraphQL-query rechts.
Vergelijk het aantal requests onder de panelen.
Lees de notitie om te zien waar elke stijl meer data stuurt dan het scherm nodig heeft.
Stap niet over van een werkende REST API naar GraphQL alleen omdat het in de mode is. De winst komt pas als veel verschillende schermen verschillende stukken gerelateerde data nodig hebben.
Geef elk GraphQL-type een stabiel id-field, zodat clientlibraries hun cache daarop kunnen normaliseren.
Controleer de errors-array bij elke GraphQL-response, ook als de status 200 is en er data is.
Stel limieten voor diepte en kosten in op een publiek GraphQL-endpoint, want één geneste query kan heel veel werk vragen.
Veelgestelde vragen
Is GraphQL sneller dan REST?
Niet vanzelf. Het kan round trips en payloadgrootte verminderen voor schermen die gerelateerde data nodig hebben, maar elke query kan de server meer kosten om op te lossen. Een goed ontworpen REST-endpoint voor één scherm kan net zo snel zijn.
Waarom komt een GraphQL-fout terug met status 200?
Een field kan falen terwijl andere slagen, dus de server stuurt de data die hij heeft plus een errors-array. De richtlijn voor GraphQL over HTTP gebruikt 2xx voor gedeeltelijk succes; servers die antwoorden met application/graphql-response+json gebruiken 400 als een request de validatie niet doorstaat.
Kan een CDN GraphQL-responses cachen?
Ja, als queries met GET worden verstuurd, wat servers alleen voor queries mogen toestaan. Lange queries kunnen URL-limieten overschrijden, dus teams gebruiken persisted queries die een korte hash sturen in plaats van het hele document.
Kan ik beide in één product gebruiken?
Veel teams doen dat. Bestandsuploads, webhooks en eenvoudige publieke resources blijven vaak REST-routes, terwijl appschermen lezen via een GraphQL-laag die daaronder dezelfde services kan aanroepen.
Heeft GraphQL een eigen database nodig?
Nee. Een GraphQL-server is een laag van resolvers, kleine functies die elk field ophalen van waar de data ook staat: een database, een REST-service of een bestand. Het schema beschrijft vormen, geen opslag.
Over-fetching en under-fetching
Een REST-endpoint geeft een vaste vorm terug. Een lijstscherm dat alleen namen toont, downloadt toch elk field van elke gebruiker; dat is over-fetching. Een detailscherm dat een gebruiker plus zijn posts plus het aantal reacties per post nodig heeft, kan meerdere calls vergen; dat is under-fetching.
GraphQL legt die keuze bij de client. De query noemt de fields, de server geeft precies die vorm terug en verder niets. Daar staat tegenover dat de server elke combinatie van fields moet kunnen afhandelen die een client kan vragen.
Caching werkt anders
Bij REST is een URL een cachesleutel. Browsers en CDN's kunnen een GET-response opslaan en hergebruiken, omdat GET en HEAD de cachebare methoden zijn. Het meeste GraphQL-verkeer is POST naar één URL, wat die caches niet opslaan.
GraphQL-clients maken dat goed in de app: ze splitsen responses op in objecten en slaan die op per id, zodat twee queries die dezelfde gebruiker raken één gecachet record delen. graphql.org raadt precies daarom een globaal uniek id-field aan.
Fouten en statuscodes
REST leunt op de statusregel: 404 voor een ontbrekend record, 401 als u niet bent ingelogd, 422 voor foute invoer. Clients kunnen alleen op de code vertakken.
Een GraphQL-response heeft een data-key, een errors-key, of beide. Een syntax- of validatieprobleem geeft errors en geen data. Een fout binnen één field geeft gedeeltelijke data waarin dat field null is, en een error-entry waarvan het path ernaar wijst.
Welke kiest u
Keuzetabel
Uw situatie
Neigt naar
Publieke API die derden met curl aanroepen
REST
Veel schermen, elk met andere gerelateerde data
GraphQL
Zware CDN-caching van leesverkeer
REST, of GraphQL met persisted GET-queries
Mobiele clients op trage netwerken
GraphQL, minder round trips
Eenvoudige CRUD over een paar tabellen
REST
Meerdere backendservices achter één voordeur
GraphQL als gatewaylaag
Wat er over de lijn gaat
Een GraphQL-request met fetch
Elke operatie is een POST van JSON met de keys query en variables naar het ene endpoint. De Accept-header vraagt om het nieuwere GraphQL-responsetype, met gewone JSON als terugval.
Een gedeeltelijke GraphQL-response
Eén field faalde, dus het is null en de errors-entry noemt het met path. De rest van de data kwam wel aan.
Profiel met posts
REST heeft een tweede call nodig voor de posts, en beide responses bevatten elk field dat de server meestuurt. De GraphQL-query geeft alleen de naam, de avatar en drie posttitels terug.
Alleen namen
Voor een eenvoudige lijst is de REST-call hoe dan ook één request, maar hij stuurt complete gebruikersrecords. GraphQL stuurt alleen de twee gevraagde fields.
Post met reacties en auteurs
Zonder een eigen endpoint loopt REST de boom één niveau per request af, en het ophalen van elke reactieauteur kan per reactie nog een call betekenen. GraphQL nest de hele boom in één query.
Een post aanmaken
Schrijfacties lijken op elkaar: elk één request. REST gebruikt de POST-methode op een collectie-URL; GraphQL stuurt een mutation, nog steeds als HTTP POST, en kiest welke fields van de nieuwe post terugkomen.