GraphQL vs. REST : quel style d’API, et quand ?

REST est un style d’API aux endpoints fixes ; GraphQL est un langage de requêtes où le client demande à un seul endpoint les seuls champs dont il a besoin. La comparaison porte en réalité sur qui décide de la forme de la réponse : en REST, le serveur l’a décidée à la conception ; en GraphQL, le client la décide à chaque requête. Tout le reste — cache, versionnage, erreurs, performance — découle de cette seule inversion.

Points clés

Le même écran, des deux façons

Un écran de profil a besoin d’un utilisateur, de ses cinq derniers posts et de son nombre d’abonnés. REST parle en ressources :

GET /users/42               → 38 champs, il vous en fallait 3   (overfetching)
GET /users/42/posts?limit=5 → deuxième aller-retour             (underfetching)
GET /users/42/followers     → troisième aller-retour

GraphQL parle en une seule question façonnée :

POST /graphql
query {
  user(id: 42) {
    name
    avatarUrl
    posts(first: 5) { title likes }
    followers { totalCount }
  }
}
→ un seul aller-retour, exactement ces champs, rien d'autre

L’écart se resserre plus que les gros titres ne le suggèrent : un REST bien conçu supporte aussi la sélection de champs — et les query builders des SDK en font une habitude de premier ordre :

// JavaScript / Node.js — Back4app JS SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
const query = new Parse.Query('Article');
query.equalTo('status', 'published');
query.select('title', 'views');        // field selection, GraphQL-style
const articles = await query.find();   // lean payload over the REST API
// The same backend also speaks real GraphQL: query { articles { ... } }

// Flutter / Dart — Back4app Flutter SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')
  ..keysToReturn(['title', 'views']);   // field selection, GraphQL-style
final response = await query.query();   // lean payload over the REST API

// iOS / Swift — Back4app Swift SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
let query = Article.query("status" == "published")
  .select("title", "views")             // field selection, GraphQL-style
query.find { result in
  if case .success(let articles) = result { render(articles) }
}

// Android / Kotlin — Back4app Android SDK
// GraphQL's best trick — ask only for what you need — without leaving REST
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")
query.selectKeys(listOf("title", "views"))  // field selection, GraphQL-style
query.findInBackground { articles, e -> if (e == null) render(articles) }

GraphQL vs. REST en un coup d’œil

Ce que les pages de comparaison passent sous silence

Le problème N+1 a déménagé, il n’est pas mort. Une requête GraphQL pour des posts-avec-auteurs déclenche naïvement un appel de resolver par post — la même pathologie N+1 que les ORM ont rendue célèbre, désormais côté serveur. Le remède standard est le batching : un loader par requête collecte les identifiants d’auteurs et les récupère en une seule requête. Adopter GraphQL sans stratégie de batching, c’est adopter le pire bug de performance de REST à une nouvelle adresse.

Les erreurs sont une décision d’exploitation. « 200 avec un tableau errors » signifie que les dashboards, les alertes et la logique CDN construits sur les codes de statut deviennent aveugles par défaut. Les équipes qui prospèrent avec GraphQL traitent l’observabilité des erreurs comme une partie de l’adoption, pas comme une réflexion après coup.

Les requêtes sans bornes ont besoin de bornes. Un endpoint flexible signifie qu’une seule requête peut traverser tout le graphe — les recommandations officielles de sécurité sont des limites de profondeur, des budgets de coût par requête et des listes d’autorisation de persisted queries pour les clients first-party. Les endpoints fixes de REST rendaient le contrôle des coûts implicite ; GraphQL en fait votre travail.

Cas d’usage courants

• GraphQL : apps mobiles sur réseaux lents, dashboards qui assemblent de nombreuses entités, produits avec des clients web + mobile + partenaires aux besoins de données divergents, itération rapide du frontend contre un schéma stable.
• REST : API publiques pour développeurs, diffusion de contenu cacheable, surfaces de webhooks et d’intégration, transfert de fichiers, appels service-à-service où la simplicité l’emporte.
• Les deux (la norme enterprise) : REST ou RPC entre services backend ; une couche GraphQL qui les agrège pour les frontends — le pattern backend-for-frontend avec un schéma.

Devriez-vous choisir GraphQL ou REST ? Matrice de décision

Le point de départ honnête : commencez en REST, ajoutez GraphQL quand la douleur du façonnage de données multi-clients arrive vraiment — et si votre plateforme génère les deux depuis un seul schéma, le choix cesse d’être architectural et devient par requête.

Limites et trade-offs

• REST : over/underfetching sur les écrans denses en données, migrations de versions, dérive de la forme des réponses entre équipes, et N endpoints de documentation.
• GraphQL : le cache exige de la machinerie, le contrôle des coûts exige de la vigilance, les resolvers exigent une discipline de batching, et le pattern 200-avec-errors exige de refaire l’observabilité.
• Les deux : aucun ne répare un mauvais modèle de données — un domaine confus produit une API confuse dans n’importe quel style, comme la thèse de REST elle-même le laisse discrètement entendre : les contraintes ont toujours porté sur l’architecture en dessous.

GraphQL et REST sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Il dissout le dilemme de cet article à la racine : les deux styles d’API sont générés depuis le même schéma — des endpoints REST cacheables par URL et une API GraphQL typée avec requêtes imbriquées — plus des SDK dont la sélection de champs (les onglets de code ci-dessus) livre le bénéfice phare de GraphQL sur l’un ou l’autre transport. Choisissez par client, changez par écran, et n’écrivez jamais la couche d’API.