Efficience IT
·Formation

Que vaut REST face à son nouveau challenger GraphQL ?

Par Louis-Arnaud Catoire

Depuis plus d'une décennie, REST (Representational State Transfer) constitue le socle architectural de la majorité des API web. Son adoption massive, sa compatibilité native avec le protocole HTTP et la richesse de son écosystème en ont fait un standard de facto. En 2012, Facebook crée GraphQL pour résoudre les problèmes de performance de son application mobile, avant de le rendre open source en 2015. Depuis, la question revient régulièrement : GraphQL est-il le successeur naturel de REST, ou ces deux approches répondent-elles à des problématiques fondamentalement différentes ?

Pour y répondre, il faut dépasser la comparaison superficielle et examiner les implications architecturales, les compromis de performance et les conséquences organisationnelles de chaque approche.

REST : un modèle centré sur les ressources

REST structure une API autour de ressources identifiées par des URI. Chaque ressource expose un endpoint dédié, manipulé via les verbes HTTP standards :

GET /blog/articles pour lister les articles, GET /blog/articles/1 pour en obtenir un spécifique, POST /blog/articles pour en créer un nouveau. Cette adhérence au protocole HTTP rend les API REST immédiatement lisibles pour tout développeur maîtrisant les fondamentaux du web.

Forces structurelles

La prévisibilité de REST constitue son premier atout. Un endpoint retourne toujours la même structure de données, ce qui simplifie le debugging, le monitoring et l'intégration. Les opérations CRUD se mappent naturellement sur les verbes HTTP (GET, POST, PUT, PATCH, DELETE), et les codes de statut standardisés (200, 201, 404, 500) fournissent un vocabulaire partagé entre client et serveur.

La mise en cache HTTP fonctionne nativement grâce aux headers standards (Cache-Control, ETag, Last-Modified). Un reverse proxy ou un CDN peut mettre en cache les réponses GET sans configuration applicative. Pour des API à fort trafic, cet avantage se traduit directement en économies d'infrastructure.

L'écosystème est par ailleurs extrêmement mature. Des outils comme Swagger (OpenAPI) génèrent automatiquement documentation interactive, SDK clients et tests de conformité. La plupart des frameworks backend proposent un support natif pour la création d'API REST.

Limites connues

Le problème de l'over-fetching et de l'under-fetching est inhérent au modèle. Un endpoint retourne une structure fixe : le client reçoit soit trop de données, soit pas assez. Pour afficher la page d'un article avec son auteur et ses commentaires, trois requêtes distinctes sont nécessaires, ce qui multiplie les allers-retours réseau et dégrade la latence perçue, en particulier sur mobile.

La gestion du versioning alourdit la maintenance au fil du temps. Maintenir plusieurs versions en parallèle (v1, v2, v3) impose de faire cohabiter des contrats d'API différents, avec le risque de divergence et la charge de dépréciation progressive.

GraphQL : un langage de requête pour API

GraphQL adopte une approche radicalement différente. Plutôt que de structurer l'accès autour de ressources, il expose un point d'entrée unique où le client décrit précisément la forme des données souhaitées :

query { article(id: 1) { title, content, author { name } } }

Le serveur renvoie exactement cette structure, ni plus ni moins. Les modifications s'effectuent via des mutations, et les subscriptions permettent de recevoir des mises à jour en temps réel lorsque les données changent côté serveur.

Forces structurelles

La flexibilité des requêtes élimine les problèmes d'over-fetching et d'under-fetching. Le client demande uniquement les champs nécessaires, ce qui réduit la bande passante consommée et simplifie le traitement côté front-end. Pour une application mobile où chaque kilo-octet compte, le gain est tangible.

Le système de typage fort agit comme un contrat explicite entre les équipes front-end et back-end. Le schéma GraphQL sert simultanément de documentation, de validation et de base pour l'autocomplétion dans des outils comme GraphiQL ou Apollo Studio. Les équipes peuvent travailler en parallèle dès que le schéma est défini.

L'évolution de l'API se fait sans versioning. Les nouveaux champs s'ajoutent sans casser les clients existants, et les champs obsolètes se déprécient progressivement via la directive @deprecated. Cette approche additive supprime la complexité de gestion de versions multiples.

Limites structurelles

La mise en cache réseau ne fonctionne pas naturellement avec un endpoint unique recevant des requêtes POST de formes variées. Des solutions existent (Persisted Queries, cache applicatif, APQ), mais elles demandent un effort d'implémentation supplémentaire par rapport au cache HTTP natif de REST.

Le monitoring et le debugging sont moins immédiats. Toutes les requêtes transitant par le même endpoint, il faut instrumenter la couche GraphQL elle-même pour distinguer les opérations dans les logs et les outils d'analyse de performance.

Défis avancés : N+1 queries et DataLoader

L'un des pièges les plus fréquents en GraphQL est le problème des requêtes N+1. Lorsqu'un client demande une liste d'articles avec leurs auteurs, le résolveur naïf exécute une requête pour récupérer les articles, puis une requête par article pour récupérer chaque auteur. Pour 50 articles, cela représente 51 requêtes SQL.

Le pattern DataLoader, introduit par Facebook, résout ce problème en regroupant et en mettant en lot (batching) les requêtes identiques au sein d'un même tick d'exécution. Au lieu de 50 requêtes individuelles pour les auteurs, une seule requête WHERE id IN (...) est exécutée. L'implémentation de DataLoader est indispensable pour toute API GraphQL en production, et son absence est la cause principale des problèmes de performance observés sur les déploiements immatures.

REST n'est pas immunisé contre ce problème, mais il se manifeste différemment : les endpoints retournent généralement des données pré-agrégées, ce qui déplace la complexité côté serveur lors de la conception de l'endpoint.

Stratégies de versioning et conception de schéma

REST impose un choix explicite de stratégie de versioning : par URI (/v2/articles), par header (Accept: application/vnd.api.v2+json) ou par paramètre de requête. Chaque approche a ses compromis en termes de routage, de documentation et de rétrocompatibilité.

GraphQL contourne ce problème par sa nature additive, mais impose en contrepartie une discipline rigoureuse dans la conception du schéma. Un schéma mal pensé dès le départ peut conduire à des impasses architecturales difficiles à corriger sans breaking change. La granularité des types, le nommage des mutations, la gestion des unions et des interfaces exigent une réflexion en amont que REST ne demande pas avec la même intensité.

En pratique, les équipes expérimentées adoptent un schema-first approach : le schéma est défini, discuté et validé avant toute implémentation, au même titre qu'un contrat OpenAPI pour REST.

Perspectives architecturales : combiner les deux approches

À l'échelle d'un système distribué, la question n'est plus REST ou GraphQL, mais comment les articuler pour tirer parti des forces de chacun.

Le pattern BFF (Backend for Frontend)

Le Backend for Frontend consiste à placer une couche d'agrégation entre les clients et les microservices. Un BFF GraphQL peut agréger les données de plusieurs API REST internes, offrant au client une interface unifiée tout en conservant la simplicité de REST pour les services backend. Cette architecture est particulièrement pertinente lorsque plusieurs clients (web, mobile, IoT) consomment les mêmes services avec des besoins de données très différents.

Performance à grande échelle

À fort trafic, REST bénéficie naturellement du cache HTTP distribué, du edge caching et de la simplicité de scaling horizontal. GraphQL demande une infrastructure dédiée : cache applicatif par champ, Persisted Queries pour réduire la taille des requêtes, analyse de complexité pour se protéger contre les requêtes abusives, et limitation de profondeur pour éviter les attaques par récursion.

Le coût opérationnel de GraphQL est donc plus élevé, mais il se justifie lorsque la flexibilité côté client réduit significativement le nombre d'endpoints à maintenir et accélère le développement front-end.

Implications organisationnelles

Le choix entre REST et GraphQL a des répercussions au-delà du code. REST favorise une organisation par domaine métier : chaque équipe possède ses endpoints et son contrat d'API. GraphQL tend vers un schéma fédéré où plusieurs équipes contribuent à un graphe unifié, ce qui nécessite une gouvernance du schéma, des conventions de nommage partagées et des outils de composition comme Apollo Federation.

Pour une équipe de cinq développeurs, la question est rarement pertinente. Pour une organisation de cinquante développeurs travaillant sur un même produit, le choix architectural influence directement l'autonomie des équipes, la vitesse de livraison et la surface de coordination nécessaire.

Pour conclure

REST et GraphQL ne sont pas des technologies concurrentes mais complémentaires. REST reste le choix le plus naturel pour les API simples, orientées CRUD, où la mise en cache HTTP et la standardisation apportent une valeur immédiate. GraphQL excelle dans les contextes où les données sont fortement interconnectées, où les clients ont des besoins hétérogènes, et où la flexibilité de requêtage réduit la prolifération d'endpoints spécialisés.

Les architectures les plus robustes combinent souvent les deux : des API REST pour les opérations bien définies et les services internes, un endpoint GraphQL en façade pour les clients ayant besoin d'agrégation et de souplesse. Le critère de décision n'est pas la modernité de la technologie, mais l'adéquation entre les contraintes du système, les compétences de l'équipe et les besoins réels des clients de l'API.

Chez Efficience IT, nous l'avons très bien compris et elles font partie intégrante de notre stack technique, dans le but de proposer à nos clients des solutions personnalisées et optimisées à leurs problèmes.

Pour aller plus loin

← Retour au blog