REST API vs GraphQL : lequel choisir ?

L'une des décisions les plus fréquentes au démarrage d'un nouveau projet est celle-ci : REST vs GraphQL — quelle approche utiliser pour construire ta couche API ? Les deux sont des façons matures et éprouvées de transporter des données entre le client et le serveur, mais elles résolvent des problèmes différents de manières différentes. Dans cet article, j'explique l'idée centrale de chaque approche, leurs forces et faiblesses, des sujets pratiques comme l'over/under-fetching et la mise en cache, et enfin quand choisir l'une ou l'autre.

L'idée centrale de chaque approche

REST modélise les ressources avec des URL. Chaque ressource a une adresse, et tu agis dessus avec des verbes HTTP (GET, POST, PUT, DELETE). Typiquement, /users/42 renvoie un utilisateur et /users/42/posts renvoie ses publications. C'est le serveur qui décide quels champs renvoyer.

GraphQL, en revanche, est un langage de requête qui passe par un seul endpoint (généralement /graphql). Le client indique exactement quels champs il veut dans une requête, et le serveur ne renvoie que ces champs. C'est donc le client, et non le serveur, qui décide de la forme des données.

Comparons les mêmes données avec les deux approches. Récupérer un utilisateur en REST :

GET /users/42

{
  "id": 42,
  "name": "Aslain",
  "email": "hello@aslain.dev",
  "createdAt": "2026-01-10"
}

Demander uniquement le nom et l'e-mail du même utilisateur en GraphQL :

query {
  user(id: 42) {
    name
    email
  }
}

La réponse correspond exactement à la forme demandée :

{
  "data": {
    "user": { "name": "Aslain", "email": "hello@aslain.dev" }
  }
}

Over-fetching et under-fetching

L'avantage le plus vanté de GraphQL tourne autour de ces deux concepts. L'over-fetching, c'est recevoir plus de données que nécessaire : en REST, /users/42 renvoie le nom, l'e-mail, la date d'inscription et peut-être dix champs de plus, mais si tu n'affiches que le nom, le reste a été transféré pour rien.

L'under-fetching, c'est ne pas obtenir assez de données en une seule requête. Pour afficher un utilisateur et ses cinq dernières publications en REST, tu dois faire deux requêtes — d'abord /users/42, puis /users/42/posts. C'est le problème des requêtes N+1. En GraphQL, tu peux tout demander imbriqué dans une seule requête :

query {
  user(id: 42) {
    name
    posts(last: 5) { title publishedAt }
  }
}

C'est un vrai gain, surtout sur mobile et en faible bande passante. Mais attention : ces problèmes peuvent aussi se résoudre côté REST. Des paramètres de sélection de champs comme ?fields=name,email réduisent l'over-fetching, tandis que des paramètres d'inclusion comme ?include=posts résolvent en grande partie l'under-fetching. Ce que GraphQL résout n'est donc pas impossible en REST ; cela demande simplement de la discipline de conception.

Mise en cache : là où REST brille

Ici, la balance penche vers REST. REST s'accorde parfaitement avec les mécanismes de cache natifs de HTTP. Comme chaque ressource a une URL unique, les navigateurs, les CDN et les reverse proxies (Nginx, Varnish, Cloudflare) peuvent facilement mettre en cache les réponses GET selon les en-têtes Cache-Control, ETag et Last-Modified.

En GraphQL, presque tout est une seule requête POST /graphql dont le corps diffère à chaque fois. La mise en cache au niveau HTTP est donc difficile ; tu déplaces généralement le cache côté client (le cache normalisé de bibliothèques comme Apollo Client, urql ou Relay) ou vers des solutions côté serveur au niveau des champs (par exemple les persisted queries). C'est puissant, mais cela demande plus de configuration.

Schéma, types et expérience développeur

GraphQL possède un système de types fort. Le schéma est un contrat : il définit explicitement quels champs existent, leurs types et leurs relations. Grâce à cela :

• Documentation automatique : des outils comme GraphiQL ou Apollo Studio génèrent une documentation vivante et navigable à partir du schéma.
• Sûreté des types : avec des générateurs de code TypeScript, tu obtiens des types de bout en bout côté client.
• Une source, plusieurs écrans : le web, le mobile et différents clients tirent tous ce dont ils ont besoin du même schéma ; l'équipe backend n'a pas à ouvrir un nouvel endpoint pour chaque écran.

Côté REST, tu peux obtenir une garantie similaire avec OpenAPI (anciennement Swagger). Le schéma OpenAPI fournit aussi documentation et génération de code client ; cependant, comme le système de types est inhérent à GraphQL, cette discipline y vient plus naturellement.

Complexité et points de vigilance

GraphQL n'est pas gratuit. Le prix de sa flexibilité, c'est de devoir résoudre toi-même certains problèmes côté serveur :

• Le problème des requêtes N+1 : les champs imbriqués peuvent lancer de nombreuses requêtes distinctes vers la base de données. Pour résoudre cela, il faut des outils de batching comme DataLoader.
• Le coût des requêtes : un client peut solliciter le serveur en envoyant une requête très profonde ou très large. Limiter la profondeur des requêtes et analyser leur coût (query cost analysis) est indispensable.
• Cache et gestion des erreurs : comme évoqué ci-dessus, le cache HTTP est faible ; de plus, GraphQL renvoie 200 OK même en cas d'échec et porte l'erreur dans le champ errors du corps, ce qui change la façon de superviser.

REST gagne sur la simplicité. Les codes de statut HTTP (404, 201, 401) sont naturellement parlants, l'écosystème d'outils est immense, et presque tout développeur connaît déjà REST. Dans les projets petits et moyens, cette simplicité est souvent le bon choix.

Quand choisir quoi ?

Il n'y a pas de règle absolue, mais ces critères facilitent la décision :

• Choisis REST : si tes ressources sont claires et simples, si le cache HTTP et les CDN sont critiques pour toi, si ton équipe connaît REST, ou si tu publies une API publique simple.
• Choisis GraphQL : si tu as de nombreux clients différents (web + mobile) voulant chacun une forme de données différente, si les relations imbriquées sont complexes, ou si les équipes backend et frontend veulent avancer vite et de façon indépendante.

Souviens-toi : ce n'est pas une guerre « l'un ou l'autre ». Beaucoup d'équipes utilisent les deux ensemble — par exemple GraphQL pour l'agrégation de données pilotée par le client, et REST pour l'upload de fichiers, les webhooks et les intégrations tierces. L'important est de regarder les vrais besoins du projet, pas l'idéologie.

Questions fréquentes

GraphQL va-t-il remplacer REST ?

Non. Même si GraphQL offre une expérience développeur plus fluide que REST dans certains scénarios, la simplicité de REST et son alignement avec le cache HTTP restent très précieux. Les deux coexistent depuis des années et continueront ; le bon outil dépend entièrement de ton cas d'usage.

GraphQL est-il plus rapide ?

Le qualifier de « plus rapide » en soi est trompeur. GraphQL peut améliorer la vitesse perçue côté client en réduisant les données inutiles sur le réseau et en combinant plusieurs requêtes en une seule. Mais si les requêtes N+1 ne sont pas bien gérées côté serveur, il peut même être plus lent que REST. La vitesse dépend de ton architecture et de ton optimisation.

Dois-je migrer mon API REST existante vers GraphQL ?

Réécrire une API REST qui fonctionne juste parce que c'est tendance a rarement du sens. Si tu ressens une réelle douleur d'over/under-fetching ou si la diversité de tes clients a augmenté, ajouter GraphQL comme une couche au-dessus du REST existant (approche gateway) est souvent la voie la plus intelligente.

Tu veux bien concevoir ton architecture d'API ? Si tu as besoin d'aide pour concevoir une API évolutive avec REST ou GraphQL côté Laravel et Node.js, contacte-moi — choisissons ensemble la meilleure approche pour ton projet.