REST vs GraphQL : quelle différence et lequel choisir ?

REST et GraphQL sont deux façons de concevoir une API — la manière convenue dont les écrans de votre application (ou d'autres programmes) demandent des données à votre backend. Avec REST, il existe une URL distincte pour chaque type d'élément, comme /customers ou /orders, et chacune renvoie une structure de données fixe. Avec GraphQL, il y a généralement une seule URL, et l'appelant envoie une requête qui liste exactement les champs qu'il veut récupérer. Pour la plupart des applications créées avec l'IA, REST est le choix par défaut, plus simple et plus adapté.

Pourquoi c'est important quand vous construisez avec l'IA

Quand vous demandez à un créateur IA « une application avec un backend », il doit choisir la manière dont le frontend et le backend communiquent. Vous n'avez pas à trancher à chaque fois, mais vous verrez ces termes dans le code, dans la documentation et lors de la connexion à des services externes. Certains services ne proposent qu'un seul style : beaucoup exposent des API REST, tandis que d'autres — Shopify et GitHub, par exemple — proposent aussi GraphQL ou le privilégient. Comprendre la différence vous aide à savoir ce que vous regardez et à éviter d'ajouter une complexité inutile. Si le mot « API » vous est nouveau, commencez par ce qu'est une API.

Une analogie du quotidien

REST, c'est un menu fixe au restaurant. Chaque plat (endpoint) arrive tel que la cuisine l'a conçu. Vous commandez le plat « client » et vous recevez toute l'assiette — nom, e-mail, adresse, date d'inscription — même si vous ne vouliez que le nom. Vous voulez aussi les commandes récentes du client ? C'est un second plat.

GraphQL, c'est commander à la carte auprès d'un seul serveur. Vous indiquez exactement ce que vous voulez : « le nom du client, ainsi que les dates et montants de ses trois dernières commandes ». Une commande, une assiette, seulement ce que vous avez demandé. Mais la cuisine doit être prête à gérer n'importe quelle combinaison que les clients pourraient écrire.

La même demande, de deux façons

Imaginons qu'une page client ait besoin du nom d'un client et de ses trois commandes les plus récentes.

Avec REST, il faut généralement deux requêtes :

GET /api/customers/42
GET /api/customers/42/orders?limit=3

La première réponse peut contenir plus que ce dont la page a besoin :

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Avec GraphQL, c'est une seule requête, généralement un POST vers un point d'entrée unique comme /graphql, qui transporte une requête :

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

Et la réponse reprend exactement la requête :

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Les deux renvoient du JSON. La différence tient à qui décide de la forme : avec REST, c'est le serveur ; avec GraphQL, c'est l'appelant, dans les limites du schéma du serveur.

Comparaison côte à côte

Où chacun trouve sa place

Choisissez REST lorsque :

• Vous construisez une application classique : un système de réservation, un CRM, un tableau de bord, une boutique.
• Un seul frontend communique avec un seul backend, et vous maîtrisez les deux.
• Vous voulez la solution la plus simple à déboguer, à mettre en cache et à sécuriser.
• D'autres services appelleront votre application (les webhooks et la plupart des intégrations attendent des endpoints de style REST).

Envisagez GraphQL lorsque :

• Plusieurs clients différents — un site web, une application mobile, des intégrations partenaires — ont besoin de portions très différentes des mêmes données.
• Vos données sont fortement liées (produits, variantes, avis, vendeurs, stocks) et les écrans doivent les combiner de nombreuses façons.
• Vous consommez un service qui propose GraphQL comme API principale.

Une règle utile : si vous n'êtes pas sûr d'avoir besoin de GraphQL, c'est probablement que non. Il est plus facile à ajouter plus tard qu'à retirer.

Termes clés

Idées reçues

• « GraphQL est plus récent, donc il est meilleur. » Il résout des problèmes précis. Pour une seule application avec un seul frontend, il ajoute souvent du travail sans grand bénéfice.
• « GraphQL est une base de données. » Ce n'est pas le cas. C'est une couche d'API ; derrière, le serveur lit toujours dans votre base de données.
• « GraphQL est toujours plus rapide. » Moins de requêtes peuvent aider sur des réseaux mobiles lents, mais une requête sans limite peut charger d'énormes volumes de données. La performance dépend du backend.
• « REST signifie une norme stricte. » En pratique, « API REST » désigne vaguement des URL de ressources, des méthodes HTTP et du JSON. Beaucoup de bonnes API contournent les règles formelles.
• « Le statut 200 signifie que ça a marché. » Avec GraphQL, vérifiez le champ errors : une requête peut échouer en partie tout en renvoyant 200.

Que demander à votre créateur IA

• « Utilise une API REST simple avec du JSON, sauf s'il existe une raison claire de faire autrement — explique-moi si tu penses que GraphQL est nécessaire. »
• « Liste chaque endpoint, ce qu'il renvoie et qui a le droit de l'appeler. »
• « Pour la page client, ne renvoie que les champs utilisés par la page. »
• « Ajoute la pagination aux endpoints de liste pour qu'ils ne renvoient jamais des milliers de lignes d'un coup. »
• « Ce service n'a qu'une API GraphQL — appelle-la depuis le serveur, garde la clé dans un secret et ne demande que les champs dont nous avons besoin. »
• « Renvoie des codes de statut HTTP appropriés et des messages d'erreur en JSON. »

REST et GraphQL dans Mythex

La documentation de Mythex comprend une recette pour construire un backend d'API REST avec un prompt de départ, et un backend peut tourner en Node, Python (FastAPI), C# ou Java à côté de votre application web. La documentation ne décrit pas de modèle GraphQL ; si vous en voulez un, demandez-le explicitement et expliquez pourquoi. Appeler une API GraphQL tierce fonctionne comme n'importe quel service externe — voir intégrer n'importe quelle API. Lectures associées : frontend vs backend et comment créer une API REST.

Questions