GraphQL vs REST : les mêmes données récupérées des deux façons | We.Inc
Comparez GraphQL et REST avec les mêmes données récupérées des deux façons : nombre de requêtes, over-fetching, mise en cache, retour des erreurs, et un tableau pour choisir.
REST expose de nombreuses URL, une par ressource, et le serveur décide du contenu de chaque réponse. GraphQL expose un seul endpoint, généralement /graphql, où le client envoie une requête qui nomme exactement les champs voulus. REST bénéficie gratuitement du cache HTTP par URL ; GraphQL économise des allers-retours et élimine les champs inutiles, au prix de plus de travail côté serveur.
En un coup d'œil
Sujet
REST
GraphQL
Endpoints
Une URL par ressource
Un seul endpoint, souvent /graphql
Qui choisit les champs
Le serveur
Le client, dans la requête
Données liées
Souvent plusieurs requêtes
Imbriquées dans une seule requête
Cache HTTP
Intégré pour GET, par URL
Nécessite des requêtes GET, des persisted queries ou un cache client
Erreurs
Surtout des codes de statut HTTP
Un tableau errors, souvent à côté de données partielles
Schéma
Optionnel (OpenAPI)
Obligatoire et typé
La comparaison ci-dessous récupère le même écran de données des deux façons. Choisissez un scénario pour voir les appels REST qu'un client ferait, à côté de l'unique requête GraphQL qui les remplace, et ce que chaque réponse omet ou ajoute.
Choisissez un scénario, comme une page de profil avec les derniers articles.
Lisez les requêtes REST à gauche et la requête GraphQL à droite.
Comparez le nombre de requêtes affiché sous les panneaux.
Lisez la note pour voir où chaque style envoie plus de données que l'écran n'en a besoin.
Ne passez pas une API REST qui fonctionne à GraphQL juste par effet de mode. Le gain apparaît quand de nombreux écrans différents ont besoin de portions différentes de données liées.
Exposez un champ id stable sur chaque type GraphQL pour que les bibliothèques client puissent normaliser leur cache à partir de lui.
Vérifiez le tableau errors de chaque réponse GraphQL, même quand le statut est 200 et que des données sont présentes.
Imposez des limites de profondeur et de coût sur un endpoint GraphQL public, car une seule requête imbriquée peut demander énormément de travail.
Questions fréquentes
GraphQL est-il plus rapide que REST ?
Pas en soi. Il peut réduire les allers-retours et la taille des réponses pour les écrans qui ont besoin de données liées, mais chaque requête peut coûter plus cher à résoudre côté serveur. Un endpoint REST bien conçu pour un écran peut être tout aussi rapide.
Pourquoi une erreur GraphQL revient-elle avec le statut 200 ?
Un champ peut échouer pendant que d'autres réussissent, donc le serveur renvoie les données dont il dispose plus un tableau errors. Les recommandations GraphQL over HTTP utilisent 2xx pour un succès partiel ; les serveurs qui répondent en application/graphql-response+json utilisent 400 quand une requête échoue à la validation.
Un CDN peut-il mettre en cache les réponses GraphQL ?
Oui, si les requêtes sont envoyées en GET, ce que les serveurs peuvent autoriser pour les seules queries. Les longues requêtes peuvent dépasser les limites d'URL, donc les équipes utilisent des persisted queries qui envoient un court hash au lieu du document entier.
Peut-on utiliser les deux dans un même produit ?
Beaucoup d'équipes le font. Les envois de fichiers, les webhooks et les ressources publiques simples restent souvent des routes REST, tandis que les écrans de l'application lisent via une couche GraphQL qui peut appeler ces mêmes services en dessous.
GraphQL a-t-il besoin de sa propre base de données ?
Non. Un serveur GraphQL est une couche de resolvers, de petites fonctions qui récupèrent chaque champ là où se trouvent les données : une base de données, un service REST ou un fichier. Le schéma décrit des formes, pas un stockage.
Over-fetching et under-fetching
Un endpoint REST renvoie une forme fixe. Un écran de liste qui n'affiche que des noms télécharge quand même chaque champ de chaque utilisateur : c'est l'over-fetching. Un écran de détail qui a besoin d'un utilisateur, de ses articles et du nombre de commentaires de chaque article peut demander plusieurs appels : c'est l'under-fetching.
GraphQL déplace ce choix vers le client. La requête liste les champs, le serveur renvoie cette forme et rien d'autre. La contrepartie est que le serveur doit gérer n'importe quelle combinaison de champs qu'un client pourrait demander.
Le cache fonctionne différemment
Avec REST, une URL est une clé de cache. Les navigateurs et les CDN peuvent stocker une réponse GET et la réutiliser, car GET et HEAD sont les méthodes que l'on peut mettre en cache. La plupart du trafic GraphQL est du POST vers une seule URL, que ces caches ne stockent pas.
Les clients GraphQL compensent dans l'application : ils découpent les réponses en objets et les stockent par id, de sorte que deux requêtes qui touchent le même utilisateur partagent un seul enregistrement en cache. graphql.org recommande un champ id globalement unique précisément pour cette raison.
Erreurs et codes de statut
REST s'appuie sur la ligne de statut : 404 pour un enregistrement manquant, 401 quand on n'est pas connecté, 422 pour une entrée invalide. Les clients peuvent se brancher sur le seul code.
Une réponse GraphQL a une clé data, une clé errors, ou les deux. Un problème de syntaxe ou de validation donne errors et pas de data. Un échec dans un champ donne des données partielles où ce champ vaut null, et une entrée d'erreur dont le path le désigne.
Lequel choisir
Tableau de décision
Votre situation
Penche vers
API publique que des tiers appellent avec curl
REST
Nombreux écrans, chacun ayant besoin de données liées différentes
GraphQL
Cache CDN intensif du trafic en lecture
REST, ou GraphQL avec des persisted queries en GET
Clients mobiles sur réseaux lents
GraphQL, moins d'allers-retours
CRUD simple sur quelques tables
REST
Plusieurs services backend derrière une seule porte d'entrée
GraphQL comme couche de passerelle
Ce qui passe sur le réseau
Une requête GraphQL avec fetch
Chaque opération est un POST de JSON avec les clés query et variables vers l'endpoint unique. L'en-tête Accept demande le type de réponse GraphQL plus récent, avec le JSON simple en repli.
Une réponse GraphQL partielle
Un champ a échoué, il vaut donc null et l'entrée errors le désigne avec path. Le reste des données est quand même arrivé.
Profil avec articles
REST a besoin d'un second appel pour les articles, et les deux réponses contiennent tous les champs inclus par le serveur. La requête GraphQL ne renvoie que le nom, l'avatar et trois titres d'articles.
Noms seulement
Pour une simple liste, l'appel REST tient en une requête dans les deux cas, mais il envoie des fiches utilisateur complètes. GraphQL n'envoie que les deux champs demandés.
Article avec commentaires et auteurs
Sans endpoint sur mesure, REST parcourt l'arbre un niveau par requête, et récupérer l'auteur de chaque commentaire peut demander un appel de plus par commentaire. GraphQL imbrique tout l'arbre dans une seule requête.
Créer un article
Les écritures se ressemblent : une requête chacune. REST utilise la méthode POST sur une URL de collection ; GraphQL envoie une mutation, toujours en HTTP POST, et choisit quels champs du nouvel article renvoyer.