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

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

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

Lorsque vous demandez à un créateur IA une « application avec un serveur », il doit choisir la façon dont l'interface et le serveur communiquent. Vous n'avez pas à trancher cette question chaque fois, mais vous verrez ces termes dans le code, dans la documentation et lorsque vous vous connectez à des services externes. Certains services n'offrent qu'un seul style : beaucoup exposent des API REST, tandis que d'autres, comme Shopify et GitHub, proposent aussi GraphQL ou le privilégient. Connaître la différence vous aide à comprendre 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 est un menu à prix fixe dans un restaurant. Chaque plat (point de terminaison) arrive tel que la cuisine l'a conçu. Vous commandez le plat « client » et vous recevez toute l'assiette : nom, courriel, 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 est une commande à la carte auprès d'un seul serveur. Vous indiquez exactement ce que vous voulez : « le nom du client, ainsi que les dates et les totaux de ses trois dernières commandes ». Une commande, une assiette, uniquement ce que vous avez demandé. Mais la cuisine doit être prête à traiter toutes les combinaisons que les clients peuvent écrire.

La même demande, de deux façons

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

Avec REST, il faut habituellement 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, habituellement un POST vers un point de terminaison unique comme /graphql, qui transporte une requête :

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

Et la réponse reflète 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 de ce que le schéma du serveur permet.

Comparaison côte à côte

Quand chacun convient

Choisissez REST lorsque :

• Vous construisez une application typique : un système de réservation, un CRM, un tableau de bord, une boutique.
• Une interface communique avec un seul serveur, et vous contrôlez 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 points de terminaison 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 très interreliées (produits, variantes, avis, vendeurs, inventaire) et les écrans doivent les combiner de multiples façons.
• Vous utilisez un service qui offre GraphQL comme API principale.

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

Termes clés

Idées reçues courantes

• « GraphQL est plus récent, donc il est meilleur. » Il résout des problèmes précis. Pour une seule application avec une seule interface, 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 elle, le serveur lit toujours votre base de données.
• « GraphQL est toujours plus rapide. » Moins de requêtes peuvent aider sur les réseaux mobiles lents, mais une requête sans limite peut charger d'énormes quantités de données. La performance dépend du serveur.
• « REST signifie une norme stricte. » En pratique, « API REST » désigne de façon approximative 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 fonctionné. » Avec GraphQL, vérifiez le champ errors : une requête peut échouer partiellement tout en renvoyant 200.

Quoi demander à votre créateur IA

• « Utilise une API REST simple avec du JSON, sauf s'il existe une raison claire de ne pas le faire; explique si tu penses que GraphQL est nécessaire. »
• « Énumère chaque point de terminaison, ce qu'il renvoie et qui est autorisé à l'appeler. »
• « Pour la page client, renvoie seulement les champs qu'utilise la page. »
• « Ajoute la pagination aux points de terminaison 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 demande seulement les champs dont nous avons besoin. »
• « Renvoie des codes d'état HTTP appropriés et des messages d'erreur en JSON. »

REST et GraphQL dans Mythex

La documentation de Mythex comprend une recette pour créer un serveur d'API REST avec une invite de départ, et un serveur peut fonctionner 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 tout autre service externe; voir intégrer n'importe quelle API. Lectures connexes : frontal vs serveur et comment créer une API REST.

Questions