REST vs GraphQL: wat is het verschil en welke gebruik je?

REST en GraphQL zijn twee manieren om een API te ontwerpen: de afgesproken manier waarop de schermen van je app (of andere programma's) je backend om gegevens vragen. Bij REST is er een aparte URL voor elk soort ding, zoals /customers of /orders, en elke geeft een vaste datastructuur terug. Bij GraphQL is er meestal één URL, en de aanroeper stuurt een query met precies de velden die hij terug wil. Voor de meeste apps die je met AI bouwt is REST de eenvoudigere en betere standaard.

Waarom dit ertoe doet als je met AI bouwt

Als je een AI-appbouwer vraagt om "een app met een backend", moet die kiezen hoe de frontend en backend met elkaar praten. Je hoeft dit niet elke keer te beslissen, maar je ziet de termen wel in code, in documentatie en bij het koppelen van externe diensten. Sommige diensten bieden maar één stijl: veel diensten stellen REST-API's beschikbaar, terwijl andere, zoals Shopify en GitHub, ook GraphQL aanbieden of die voorkeur geven. Weten wat het verschil is, helpt je begrijpen wat je ziet en voorkomt dat je complexiteit toevoegt die je niet nodig hebt. Als "API" nieuw voor je is, begin dan met wat een API is.

Een dagelijkse vergelijking

REST is een vast menu in een restaurant. Elk gerecht (endpoint) komt zoals de keuken het heeft bedacht. Bestel je het "klant"-gerecht, dan krijg je het hele bord: naam, e-mail, adres, aanmelddatum, ook als je alleen de naam wilde. Wil je ook de recente bestellingen van de klant? Dat is een tweede gerecht.

GraphQL is à la carte bestellen bij één ober. Je schrijft precies op wat je wilt: "de naam van de klant, en de datums en totalen van de laatste drie bestellingen." Eén bestelling, één bord, alleen wat je vroeg. Maar de keuken moet zo zijn ingericht dat ze elke combinatie aankan die klanten opschrijven.

Hetzelfde verzoek, op twee manieren

Stel dat een klantpagina de naam van een klant nodig heeft plus de drie meest recente bestellingen.

Met REST zijn dat meestal twee verzoeken:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

De eerste respons kan meer bevatten dan de pagina nodig heeft:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Met GraphQL is het één verzoek, meestal een POST naar één endpoint zoals /graphql, met een query:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

En de respons spiegelt de query precies:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Beide geven JSON terug. Het verschil is wie de vorm bepaalt: bij REST doet de server dat; bij GraphQL doet de aanroeper dat, binnen wat het schema van de server toestaat.

Vergelijking naast elkaar

Waar elk past

Kies REST wanneer:

• Je een gewone app bouwt: een boekingssysteem, een CRM, een dashboard, een webwinkel.
• Eén frontend met één backend praat, en je beide beheert.
• Je het eenvoudigst te debuggen, cachen en beveiligen wilt houden.
• Andere diensten je app gaan aanroepen (webhooks en de meeste integraties verwachten REST-achtige endpoints).

Overweeg GraphQL wanneer:

• Verschillende clients, zoals een website, een mobiele app en partnerintegraties, heel verschillende delen van dezelfde gegevens nodig hebben.
• Je gegevens diep verbonden zijn (producten, varianten, reviews, verkopers, voorraad) en schermen die op veel manieren moeten combineren.
• Je een dienst gebruikt die GraphQL als hoofd-API aanbiedt.

Een bruikbare vuistregel: als je niet zeker weet of je GraphQL nodig hebt, dan waarschijnlijk nog niet. Het is makkelijker later toe te voegen dan weg te halen.

Belangrijke termen

Veelvoorkomende misverstanden

• "GraphQL is nieuwer, dus het is beter." Het lost specifieke problemen op. Voor één app met één frontend voegt het vaak werk toe zonder veel voordeel.
• "GraphQL is een database." Dat is het niet. Het is een API-laag; erachter leest de server nog steeds uit je database.
• "GraphQL is altijd sneller." Minder verzoeken kunnen helpen op trage mobiele netwerken, maar een onbegrensde query kan enorme hoeveelheden gegevens laden. De prestaties hangen af van de backend.
• "REST betekent een strikte standaard." In de praktijk betekent "REST-API" losjes: resource-URL's plus HTTP-methoden en JSON. Veel goede API's buigen de formele regels.
• "Status 200 betekent dat het gelukt is." Bij GraphQL moet je het veld errors controleren: een verzoek kan gedeeltelijk mislukken en toch 200 teruggeven.

Wat je aan je AI-builder kunt vragen

• "Gebruik een eenvoudige REST-API met JSON, tenzij er een duidelijke reden tegen is. Leg uit als je denkt dat GraphQL nodig is."
• "Geef elk endpoint, wat het teruggeeft en wie het mag aanroepen."
• "Geef voor de klantpagina alleen de velden terug die de pagina gebruikt."
• "Voeg paginering toe aan lijst-endpoints, zodat ze nooit duizenden rijen tegelijk teruggeven."
• "Deze dienst heeft alleen een GraphQL-API: roep hem aan vanaf de server, bewaar de sleutel als geheim en vraag alleen de velden op die we nodig hebben."
• "Geef juiste HTTP-statuscodes en JSON-foutmeldingen terug."

REST en GraphQL in Mythex

De documentatie van Mythex bevat een recept voor het bouwen van een REST-API-backend met een startprompt, en een backend kan draaien in Node, Python (FastAPI), C# of Java naast je webapp. De documentatie beschrijft geen GraphQL-template, dus als je die wilt, vraag er dan expliciet om en zeg waarom. Een GraphQL-API van derden aanroepen werkt net als elke andere externe dienst; zie elke API integreren. Aanvullende lectuur: frontend vs backend en hoe je een REST-API bouwt.

Veelgestelde vragen