REST vs GraphQL vs gRPC — quand choisir chacun ?

Question

IT Interview Practice · Accepted Answer

Ce sont trois paradigmes d'API différents, chacun optimisé pour des contraintes différentes. Il n'y a pas de vainqueur universel — le bon choix dépend du **consommateur, de la forme des données, et du réseau**.

## Les trois en un coup d'œil

```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

Orienté ressource sur du HTTP simple. **Choisissez-le** pour les API publiques, les services CRUD, et tout ce qui bénéficie du caching HTTP, de l'ubiquité et de la simplicité. Ses faiblesses sont l'**over-fetching** (vous obtenez tout le `/users/42` même si vous n'avez besoin que d'un champ) et l'**under-fetching** (le problème `N+1` : récupérer un user, puis boucler pour récupérer chaque order).

```http
GET /users/42            → l'user entier
GET /users/42/orders     → un deuxième aller-retour
```

## GraphQL

Un endpoint unique où **le client spécifie exactement ce qu'il veut** en une seule query, résolvant l'over/under-fetching. **Choisissez-le** pour les frontends riches (surtout mobile, où les allers-retours coûtent cher) et quand de nombreux clients ont besoin de formes différentes des mêmes données.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← un aller-retour, champs exacts
```
Compromis : le caching HTTP est plus difficile (tout est un `POST` vers `/graphql`), et un resolver naïf peut cacher des requêtes de base de données `N+1` coûteuses.

## gRPC

RPC contract-first utilisant **Protobuf** sur **HTTP/2**. Binaire et multiplexé, donc rapide et compact avec support du streaming. **Choisissez-le** pour la communication **service-to-service interne** dans un backend microservices où la performance et le typage strict comptent. Faiblesse : mauvais support des navigateurs (nécessite un proxy comme grpc-web) et non lisible par un humain.

## Choisir

```text
API publique, CRUD, caching, large portée    → REST
Besoins de données frontend complexes/variés  → GraphQL
Microservices internes haute performance      → gRPC
(Les systèmes réels les mélangent : REST/GraphQL en périphérie, gRPC entre les services.)
```

## Pourquoi c'est important

Au niveau senior, les recruteurs se soucient moins des définitions que de savoir si vous pouvez **justifier un choix face à des contraintes** — cette question est en réalité « pouvez-vous faire correspondre une technologie à un problème au lieu de courir après la hype ? ». Les meilleures réponses s'ancrent sur la douleur que chacun résout : GraphQL existe pour éliminer l'over/under-fetching des frontends exigeants, gRPC existe pour rendre les appels de services internes rapides et fortement typés, et REST reste le choix par défaut car le caching HTTP, l'outillage et la familiarité universelle sont d'énormes avantages pratiques pour les API publiques et de style CRUD. Surtout, un ingénieur senior note que ce n'est **pas l'un ou l'autre** — une architecture courante est REST ou GraphQL à la périphérie publique avec gRPC entre les microservices backend — et nomme les compromis concrets (les risques de caching et de `N+1` de GraphQL, la faible histoire navigateur de gRPC). Ce raisonnement sur l'adéquation et le coût, et non la capacité à réciter des fonctionnalités, est le signal.

Les trois en un coup d'œil

REST

GraphQL

gRPC

Choisir

Pourquoi c'est important

Questions connexes