Programmation · web · API

REST vs GraphQL

Vous construisez une API et la première grande bifurcation, c’est le style : REST ou GraphQL. Ils résolvent le même problème — laisser des clients lire et écrire des données via HTTP — mais placent le contrôle dans des mains différentes. Ce guide les compare honnêtement sur la récupération de données, le cache, la complexité et l’outillage, pour choisir en connaissance de cause.

La différence fondamentale

• REST — de nombreux endpoints (URL), chacun renvoyant une forme fixe de données. Vous appelez /users/42 et obtenez ce que cet endpoint est fait pour renvoyer. C’est le serveur qui décide la forme.
• GraphQL — un seul endpoint où le client envoie une requête nommant exactement les champs voulus, et ne reçoit que ceux-là. C’est le client qui décide la forme.

Les deux passent par HTTP et parlent en général JSON. La différence : qui contrôle ce qui revient.

La même requête, des deux façons

Récupérer le nom d’un utilisateur et les titres de ses posts. En REST c’est souvent deux appels ; en GraphQL une requête précise :

-- REST (souvent deux allers-retours)
GET /users/42
GET /users/42/posts

-- GraphQL (une requête, champs exacts)
POST /graphql
{ user(id: 42) { name posts { title } } }

Sur-fetching et sous-fetching

C’est l’argument phare de GraphQL. Avec les réponses fixes de REST, vous rencontrez souvent :

• Le sur-fetching — l’endpoint renvoie bien plus que nécessaire (des dizaines de champs pour afficher un nom).
• Le sous-fetching — un endpoint ne suffit pas, vous faites plusieurs autres appels pour construire un écran.

GraphQL évite les deux : le client demande exactement les champs voulus, en une requête. Pour des apps à nombreux écrans (surtout mobiles), cette précision est la raison principale d’adoption.

Là où REST gagne encore

• Cache — URL distinctes + GET font fonctionner REST naturellement avec les caches HTTP et CDN. GraphQL (POST vers un endpoint) nécessite un cache client ou des requêtes persistées.
• Simplicité — pour des données orientées ressources, REST est moins à apprendre et à exploiter ; pas de schéma, resolvers ni limites de coût de requête.
• Outillage & ubiquité — REST est partout, avec un outillage mature et gratuit et une courbe d’apprentissage douce.

Là où GraphQL gagne

• Données flexibles et précises — les clients récupèrent exactement ce dont ils ont besoin, pas plus.
• Moins d’allers-retours — des données liées en une seule requête au lieu de plusieurs appels.
• Un schéma typé — un contrat auto-documenté et un outillage puissant (introspection, codegen).

Le coût : plus de complexité serveur (schéma, resolvers, protection contre les requêtes coûteuses) et un cache à concevoir plutôt qu’obtenu gratuitement.

Comment choisir

• Prenez REST pour des API plus simples, orientées ressources, où le cache HTTP gratuit, l’ubiquité et une courbe douce comptent.
• Prenez GraphQL quand les clients ont des besoins de données variés et évolutifs et que vous voulez éviter le sur/sous-fetching — et pouvez absorber la complexité serveur en plus.
• Les deux, c’est bien — beaucoup de systèmes exposent REST pour l’accès simple/public et GraphQL pour les apps clientes riches.

Questions fréquentes

Quelle est la différence entre REST et GraphQL ?

REST et GraphQL sont deux styles pour construire une API web. Une API REST expose de nombreuses URL (endpoints), chacune renvoyant une forme de données fixe — vous appelez /users/42 et obtenez ce que cet endpoint renvoie. GraphQL expose un seul endpoint où le client envoie une requête décrivant exactement les champs voulus, et ne reçoit que ceux-là. En bref : avec REST le serveur décide la forme de la réponse par endpoint ; avec GraphQL le client la décide par requête. Les deux passent par HTTP et échangent en général du JSON.

GraphQL est-il meilleur que REST ?

Aucun n’est universellement meilleur — ils échangent des compromis différents. GraphQL brille quand les clients ont besoin de données flexibles et précises (ex. écrans mobiles variés) car il évite le sur-fetching et le sous-fetching et regroupe plusieurs appels en une requête. REST brille pour des API simples orientées ressources et profite d’un cache HTTP gratuit et mature et d’un outillage solide. GraphQL ajoute de la complexité serveur (schéma, resolvers, contrôle du coût des requêtes) ; REST peut exiger plusieurs allers-retours. Choisissez selon les besoins de données de vos clients, pas selon la mode.

Qu’est-ce que le sur-fetching et le sous-fetching ?

Le sur-fetching, c’est quand un endpoint renvoie plus de données que nécessaire — vous demandez un utilisateur et recevez des dizaines de champs pour n’afficher qu’un nom, gaspillant de la bande passante. Le sous-fetching, c’est quand un endpoint n’en renvoie pas assez, vous obligeant à plusieurs appels pour assembler ce qu’un écran demande. REST y est sujet car chaque endpoint a une réponse fixe. GraphQL les évite en laissant le client demander exactement les champs voulus en une requête — c’est son principal attrait.

REST ou GraphQL : lequel se met le mieux en cache ?

REST est généralement plus simple à mettre en cache. Comme REST utilise des URL distinctes et des méthodes HTTP (surtout GET pour les lectures), il fonctionne naturellement avec le cache HTTP, les CDN et le cache navigateur indexés sur l’URL. GraphQL envoie en général les requêtes en POST vers un seul endpoint, donc le cache HTTP standard ne s’applique pas d’emblée, et vous vous reposez sur un cache côté client (comme Apollo) ou des requêtes persistées. Si un cache HTTP standard et gratuit compte beaucoup pour vous, c’est un point pour REST.

En résumé

REST et GraphQL ne sont pas ennemis — ce sont deux réponses à « qui décide la forme de la réponse ? ». REST la garde côté serveur avec des endpoints simples et cachables ; GraphQL la confie au client pour des requêtes précises et flexibles, au prix d’une complexité accrue. Choisissez selon les besoins de données de vos clients et votre appétit pour la complexité opérationnelle — et rappelez-vous que vous pouvez utiliser les deux là où chacun convient.