GraphQL vs REST voor enterprise commerce (2026)

REST is een stijl voor applicatieprogrammeerinterfaces (API's) die werkt met meerdere vaste endpoints, die elk een vaste set data teruggeven. GraphQL is een querytaal en API-architectuur met één endpoint, waarbij de client in één query precies aangeeft welke data hij wil hebben.

De keuze tussen GraphQL vs REST heeft gevolgen voor je site: hoeveel data er tussen je systemen heen en weer gaat, hoeveel verzoeken een pagina nodig heeft en hoe je integraties zich in de loop van de tijd ontwikkelen. Shopify maakte GraphQL tot zijn definitieve API. In het jaar daarvoor verdubbelden we de rate limits van GraphQL en verlaagden we de kosten van connection-query's met 75%.

In deze gids lees je hoe GraphQL en REST van elkaar verschillen en waar ze allebei het best passen. Je krijgt ook een beslismodel voor enterprise-commerceteams die tussen de twee moeten kiezen.

REST: de traditionele aanpak

Een e-commerce-API regelt de uitwisseling van data tussen systemen. Een client stuurt een verzoek naar een endpoint op een server en de server antwoordt met data.

REST staat voor Representational State Transfer. API's die erop zijn gebouwd, heten RESTful API's of REST-API's. Ze bestaan sinds begin jaren 2000 en werden de standaard voor webservices, omdat ze communiceren en data overdragen met standaard HTTP-methoden als GET, POST, PUT en DELETE.

REST heeft duidelijke sterke punten, en die verklaren waarom het nog altijd zoveel wordt gebruikt:

• Voorspelbare endpoints: elke resource heeft een eigen URL, dus iets als /products/123 betekent altijd hetzelfde.
• Breed ondersteund: elke programmeertaal, gateway en monitoringtool begrijpt REST.
• Bekende HTTP-statuscodes: een 404 of 429 vertelt de client wat er gebeurde, zonder dat die de response hoeft te ontleden.
• Ingebouwde HTTP-caching: omdat elk GET-verzoek een vaste URL heeft, kunnen browsers, content delivery networks (CDN's) en proxy's responses zonder extra werk cachen.

REST werkt nog steeds goed voor eenvoudige bewerkingen per resource: webhooks, bestandsuploads, openbare data die alleen gelezen wordt en integraties waarbij de tools van een partner REST verwachten. Uit het rapport ‘State of the API’ van Postman blijkt dat 93% van de teams nog altijd REST gebruikt.

Toch laat REST in sommige situaties met hoge prestatie-eisen zwakke plekken zien. REST-endpoints geven een vaste set data terug, en dat kan tot twee samenhangende problemen leiden:

• Overfetching: het endpoint geeft het volledige productrecord terug, terwijl de client alleen de voorraad nodig heeft.
• Underfetching: het endpoint geeft niet alles terug wat de client nodig heeft, dus de client moet meerdere endpoints aanroepen om één weergave samen te stellen.

Eén pagina kan zelfs tegelijk last hebben van overfetching en underfetching.

Toen mobiel en cloudcomputing in de jaren 2000 en begin jaren 2010 opkwamen, werden die inefficiënties steeds duidelijker. Uiteindelijk bedacht een bedrijf dat onder enorme druk stond om zijn site sneller te maken iets nieuws.

GraphQL: een efficiënter alternatief

Facebook begon in 2012 met de ontwikkeling van GraphQL, tijdens het herbouwen van zijn mobiele apps en maakte het in 2015 open source. Sinds 2018 beheert de GraphQL Foundation, ondergebracht bij de Linux Foundation, de specificatie. Inmiddels gebruiken grote webplatforms over de hele wereld GraphQL.

GraphQL lost de problemen van overfetching en underfetching van REST-API's op met een querytaal. De client vraagt alleen de data op die hij wil, en de server geeft precies terug wat er werd gevraagd: niet meer en niet minder.

Zo werkt een GraphQL-schema

Een GraphQL-API wordt gedefinieerd door een schema. Dat schema beschrijft elk type in het systeem (zoals Product, Variant, Order en Customer) en de velden van elk type. Het legt ook de relaties tussen die types vast, zodat één query data kan ophalen van een order, de orderregels en elk product, zonder losse verzoeken.

Het schema ondersteunt drie soorten bewerkingen:

• Queries lezen data.
• Mutations maken data aan, wijzigen of verwijderen die.
• Subscriptions sturen updates naar de client zodra data verandert.

Omdat het schema sterk getypeerd is, valideert de GraphQL-server elk verzoek voordat het wordt uitgevoerd en weigert hij alles wat vraagt om een veld dat niet bestaat.

Het schema is bovendien introspecteerbaar. Een client kan de API vragen zichzelf te beschrijven. Daardoor werkt automatisch aanvullen in tools als GraphiQL, en signaleren ontwikkelomgevingen fouten al voordat een query draait.

Hier zie je een voorbeeld uit e-commerce. De query vraagt de titel van een product op, de eerste twee varianten met prijs en voorraad en de uitgelichte afbeelding van het product:

{

  product(handle: "trail-runner") {

    title

    featuredImage { url }

    variants(first: 2) {

      nodes {

        title

        price { amount currencyCode }

        availableForSale

      }

    }

  }

}

Het antwoord heeft dezelfde vorm als de query. Velden waar de client niet om vroeg (zoals beschrijvingen, tags of SEO-metadata) verlaten de server niet. Bij REST krijgt de client de vaste response van het product-endpoint, en moet hij aparte verzoeken doen voor data die daar niet in zit, zoals metavelden.

GraphQL werd populair omdat het probleem waar Facebook vroeg tegenaan liep, nu voor veel bedrijven speelt: hoe bouw je complexe, data-intensieve applicaties die toch snel en stabiel zijn? Dat probleem delen de kleinste webshops en de grootste enterprisemerken.

Zes voordelen van GraphQL voor enterprise commerce

De verschillen tussen GraphQL en REST lijken misschien klein, maar API's vormen het fundament van een commercewebsite. Net als bij het fundament van een huis kan je API-keuze zorgen voor stabiliteit op de lange termijn of voor constructieproblemen terwijl je al het andere bouwt en onderhoudt. Die problemen worden het duidelijkst en het ingrijpendst op grote schaal, en dat zie je vooral in enterprise commerce.

Dit zijn de belangrijkste verschillen tussen GraphQL vs REST op een rij:

Natuurlijk heeft de flexibiliteit van GraphQL ook een keerzijde. Omdat de client de query bepaalt, kan één slecht geschreven verzoek veel zwaarder zijn dan welke REST-aanroep ook. De server doet ook meer werk: elk veld heeft een resolver nodig en de server moet zich beschermen tegen geneste query's die veel databaseverzoeken veroorzaken.

Enterpriseteams die met GraphQL werken, hebben daarom duidelijke, strikte afspraken nodig over het schema en het gedrag van query's. Denk aan limieten voor querykosten en querydiepte, en gedeeld eigenaarschap van het schema. Neem die vanaf het begin op in je eisen voor enterprisesoftware.

Hieronder lees je welke voordelen GraphQL een sterke keuze maken waar het het best past: bij verschillende clients, verbonden datamodellen, meerdere databronnen en winkelervaringen waarbij snelheid telt.

1. Geschikt voor complexe data

Data in enterprise commerce vormt een netwerk van met elkaar verbonden onderdelen, dat je kunt zien als een graaf. Een product heeft varianten en elke variant heeft voorraad op verschillende locaties. Een order verwijst naar klanten, kortingen en fulfilment. Een B2B-account heeft eigen prijslijsten en betalingsvoorwaarden. REST maakt van die structuren platte endpoints per resource. Hoe groter het datamodel, hoe meer API-aanroepen er nodig zijn voor één weergave. De latentie groeit mee met de graaf.

GraphQL is juist rond dit soort data ontworpen. Een schema beschrijft de relaties direct, zodat één query precies de data teruggeeft die een weergave nodig heeft. Daarom is GraphQL een belangrijk onderdeel van het uniforme datamodel van Shopify.

Westernkledingretailer Tecovas zocht een systeem met sterke API's naast de basisfuncties. ‘Ik zoek systemen die de dagelijkse problemen voor me oplossen, maar ook uitbreidbaar zijn, een robuuste set API's hebben en maatwerk mogelijk maken voor onze specifieke bedrijfsprocessen’, zegt Kevin Harwood, CTO van Tecovas.

Tecovas gebruikt Shopify POS als volledig geïntegreerd voorraadsysteem. Medewerkers zien direct de actuele voorraad als een klant naar een bepaald artikel vraagt. De maatwerkwebshop van Tecovas is gebouwd op Shopify Hydrogen, dat product-, collectie- en winkelwagendata ophaalt via de GraphQL Storefront API.

2. Minder dataoverdracht

REST-endpoints geven een vaste set data terug, die meer kan zijn dan de client nodig heeft (overfetching). Meer data teruggeven dan nodig is, is inefficiënt en kan vertraging veroorzaken.

In enterprise commerce telt elke milliseconde. Volgens onderzoek van Shopify daalt de conversie gemiddeld met zo'n 1,5% voor elke 32 milliseconden die een winkel trager reageert op interacties.

GraphQL beperkt het ophalen van data tot de velden waar de client om vraagt. Door onnodige dataoverdracht te schrappen, verbruiken systemen met GraphQL-API's minder bandbreedte en presteren ze beter.

3. Minder verzoeken naar de server

Omdat REST-endpoints niet precies op datapunten kunnen mikken, kan één weergave meerdere verzoeken nodig hebben (underfetching). Elk verzoek is een volledige rondgang naar de server en terug.

Een productpagina is een goed voorbeeld. In de REST Admin API van Shopify komt een product binnen als één vaste payload, en voor gerelateerde data zoals metavelden zijn extra verzoeken nodig. Voor een volledige productweergave heb je dus meerdere aanroepen nodig, die elk velden teruggeven die de pagina niet gebruikt. Met GraphQL kost dezelfde weergave één query met alleen de velden die nodig zijn.

Vermenigvuldig dat met een catalogussynchronisatie, een koppeling met je ERP-systeem (enterprise resource planning) of een kassa-app (POS) die realtime de voorraad checkt. Het verschil is meetbaar. Minder verzoeken betekent kortere laadtijden en een soepelere gebruikerservaring.

4. Betere ontwikkelaarservaring

Veel ontwikkelaars kennen REST door de lange geschiedenis. GraphQL vraagt in het begin misschien meer van ze, maar betaalt dat terug met tooling. Het schema is sterk getypeerd en documenteert zichzelf. Een ontwikkelaar kan een onbekende API verkennen, query's automatisch laten aanvullen en fouten vinden voordat er iets draait. Een sterk getypeerd schema helpt bovendien om de data-integriteit op lange termijn te bewaken.

Er zijn wel een paar aandachtspunten waar enterpriseteams rekening mee moeten houden:

• Foutafhandeling: GraphQL geeft HTTP 200 terug, ook als een deel van de query mislukt, met de details in een errors-array. De GraphQL Admin API van Shopify documenteert dit verschil expliciet. Clients moeten dus de response zelf controleren in plaats van op statuscodes te vertrouwen.
• Complexiteit aan de serverkant: elk veld heeft een resolver nodig. Simpele resolvers kunnen per item in een lijst een aparte databasequery uitvoeren (het N+1-probleem). Batching en caching lossen dit op, maar iemand moet die wel bouwen.
• Governance: clients schrijven hun eigen query's, dus de eigenaar van de API moet limieten publiceren voor querykosten of -diepte. Wijzigingen in het schema moeten bovendien door alle betrokken teams worden beoordeeld. De Admin API van Shopify hanteert bijvoorbeeld rate limits op basis van berekende querykosten in plaats van het aantal verzoeken.

5. Makkelijker doorontwikkelen

API's veranderen in de loop van de tijd. Bij REST betekent een ingrijpende wijziging in de vorm van een response een nieuwe versie (/v2/) en een migratieperiode voor elke client.

GraphQL is ontworpen om een schema door te ontwikkelen zonder versienummers. Nieuwe velden kun je altijd toevoegen. Bestaande clients merken daar niets van, omdat ze alleen de velden krijgen waar ze om vragen. Oude velden krijgen een deprecation-markering: ze geven nog steeds data terug, maar waarschuwen ontwikkelaars in hun tooling. Verwijderde velden geven bij de validatie een foutmelding, nog voordat de query draait.

Dat maakt ingrijpende wijzigingen niet onmogelijk. Daarom brengt Shopify zijn API's nog steeds elk kwartaal in een nieuwe versie uit. Wat GraphQL wegneemt, is de noodzaak om de hele API een nieuwe versie te geven zodra één veld verandert.

6. Betere prestaties

Al deze voordelen kunnen abstract klinken. Hoe zie je ze terug in de praktijk? Op basis van bijna 200.000 openbaar beschikbare datapunten laden Shopify-winkels tot 2,4 keer sneller en gemiddeld 1,8 keer sneller, dan winkels op andere platforms.

GraphQL is daarbij één factor in de snelheid van Shopify, niet de hele verklaring. Snelheid komt ook van het platform: wereldwijde hosting, levering via een CDN, browsercaching, compressie en beeldoptimalisatie. GraphQL vermindert de hoeveelheid data en het aantal verzoeken dat een pagina nodig heeft. Het platform bepaalt hoe snel de rest van de pagina binnenkomt.

Shopify en GraphQL

Shopify begon GraphQL te gebruiken toen Facebook het openbaar maakte. Destijds waren er nauwelijks best practices, en als early adopter leerden we GraphQL van de grond af aan kennen. Sindsdien is GraphQL veel populairder en nog belangrijker geworden voor de infrastructuur van Shopify, en Shopify-webshops plukken daar de vruchten van.

In oktober 2024 kondigden we aan dat GraphQL de definitieve API van Shopify wordt. Sinds 1 april 2025 moeten alle nieuwe apps die worden ingediend bij de Shopify App Store GraphQL gebruiken. De REST Admin API is gemarkeerd als legacy, maar werkt nog wel. Nieuwe platformfuncties komen eerst in GraphQL beschikbaar, en sommige alleen in GraphQL, zoals ondersteuning voor 2.000 productvarianten en metaobjecten.

De Storefront API gebruikt GraphQL en de Admin API is beschikbaar via GraphQL. Tools als Functions, UI-extensies en App Bridge gebruiken GraphQL als belangrijkste API-interface.

Allebei gebruiken tijdens een enterprisemigratie

Bij een modernisering van je platform hoef je niet alle integraties tegelijk om te zetten. REST en GraphQL een tijd naast elkaar gebruiken wordt ondersteund, en zo pakte Skullcandy het ook aan.

Skullcandy migreerde in 90 dagen naar Shopify. Het merk verving een eigen checkout van vijf stappen door Shopify Checkout en stopte met een los systeem voor productinformatiebeheer (PIM). Orderverwerking draait op REST-API's en webhooks. Grote voorraadwijzigingen lopen via de GraphQL API, waarmee honderden voorraadregels in één aanroep worden bijgewerkt in plaats van één voor één. Dezelfde REST- en GraphQL-interfaces vormen ook de basis voor nieuwe apps.

Na de overstap naar Shopify zag Skullcandy direct resultaat. De laadtijd van de homepage daalde de dag na de lancering van 2,8 naar 0,8 seconden. Het eerste volledige feestdagenseizoen op Shopify leverde 45% meer omzet op dan het jaar ervoor. De grootste productlancering trok 200% meer bezoekers, zonder enig prestatieprobleem.

GraphQL vs REST: wanneer kies je wat?

REST en GraphQL draaien vandaag allebei in productie bij Shopify. De praktische vraag is welke je per toepassing gebruikt.

Kies GraphQL bij:

• Complexe datamodellen: producten met veel varianten, voorraad op meerdere locaties, B2B-prijslijsten of metaobjecten die je samen moet ophalen
• Verschillende clients: web, mobiel, kassa en AI-agents die elk een ander deel van dezelfde data nodig hebben
• Maatwerkwebshops: headless builds op Hydrogen of een ander framework, waarbij de laadsnelheid afhangt van zo min mogelijk verzoeken
• Integraties die lang meegaan: koppelingen met ERP, orderbeheersystemen (OMS) en PIM die jarenlang moeten meegroeien zonder te breken

REST past nog steeds bij:

• eenvoudige lees- of schrijfacties op één resource;
• integraties waarbij de tools van een partner REST verwachten, of die al gebouwd en stabiel zijn;
• webhooks en bestandsuploads.

Allebei gebruiken tijdens een migratie kan prima. Laat bestaande REST-integraties draaien en begin nieuw werk in GraphQL. Zet eerst de integraties met het meeste volume of de meeste complexiteit om, want daar is de winst het grootst. Zie die volgorde als onderdeel van een breder IT-transformatieplan, niet als eenmalige herbouw.

Voor enterprise commerce op Shopify past GraphQL in veel situaties beter. Het is de API waarop nieuwe functies verschijnen en de API waar de eigen tooling van Shopify omheen is gebouwd.