REST vs GraphQL vs gRPC — wanneer zou je welke kiezen?

Question

IT Interview Practice · Accepted Answer

Dit zijn drie verschillende API-paradigma's, elk geoptimaliseerd voor andere constraints. Er is geen universele winnaar — de juiste keuze hangt af van de **consumer, de datavorm en het netwerk**.

## De drie in één oogopslag

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Resource-georiënteerd over kaal HTTP. **Kies het** voor publieke API's, CRUD-services, en alles wat profiteert van HTTP-caching, alomtegenwoordigheid en eenvoud. Zijn zwaktes zijn **over-fetching** (je krijgt de hele `/users/42` ook al heb je één veld nodig) en **under-fetching** (het `N+1`-probleem: haal een user op, loop dan om elke order op te halen).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Eén endpoint waar de **client precies specificeert wat hij wil** in één query, wat over-/under-fetching oplost. **Kies het** voor rijke frontends (vooral mobiel, waar round trips duur zijn) en wanneer veel clients verschillende vormen van dezelfde data nodig hebben.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Afwegingen: HTTP-caching is lastiger (alles is een `POST` naar `/graphql`), en een naïeve resolver kan dure `N+1`-databasequeries verbergen.

## gRPC

Contract-first RPC met **Protobuf** over **HTTP/2**. Binair en gemultiplext, dus snel en compact met ondersteuning voor streaming. **Kies het** voor **interne service-to-service**-communicatie in een microservices-backend waar performance en strikte typering ertoe doen. Zwakte: slechte browserondersteuning (heeft een proxy zoals grpc-web nodig) en niet mensleesbaar.

## Kiezen

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Waarom het belangrijk is

Op seniorniveau geven interviewers minder om definities en meer om of je een **keuze tegen constraints kunt verantwoorden** — deze vraag is eigenlijk "kun je een technologie aan een probleem koppelen in plaats van hypes na te jagen?" De sterkste antwoorden verankeren zich in de pijn die elk oplost: GraphQL bestaat om over-/under-fetching te doden voor veeleisende frontends, gRPC bestaat om interne service-calls snel en sterk getypeerd te maken, en REST blijft de default omdat HTTP-caching, tooling en universele vertrouwdheid enorme praktische voordelen zijn voor publieke en CRUD-achtige API's. Cruciaal is dat een senior engineer opmerkt dat het **geen of-of** is — een gangbare architectuur is REST of GraphQL aan de publieke rand met gRPC tussen backend-microservices — en de concrete afwegingen benoemt (de caching- en `N+1`-risico's van GraphQL, het zwakke browserverhaal van gRPC). Die redenering over fit en kosten, niet het vermogen om features op te dreunen, is het signaal.

De drie in één oogopslag

REST

GraphQL

gRPC

Kiezen

Waarom het belangrijk is

Gerelateerde vragen