GraphQL a révolutionné la façon dont les clients consomment les APIs. Mais REST n'est pas mort pour autant. Le choix dépend du contexte, de l'équipe et des besoins de vos consommateurs.
REST est la référence depuis vingt ans pour une bonne raison : sa simplicité. Des ressources identifiées par des URLs, des verbes HTTP standardisés, un modèle mental que tout développeur connaît. Il s'appuie sur des fondations éprouvées (caching HTTP, stateless, etc.) et bénéficie d'un écosystème d'outils immense. Pour une API publique ou des services internes simples avec peu de clients variés, REST reste le choix par défaut.
GraphQL brille dans les contextes où les clients ont des besoins de données très différents. Une application mobile qui doit minimiser la bande passante, un frontend complexe qui agrège des données de plusieurs sources, une équipe produit qui fait évoluer ses écrans fréquemment — dans ces cas, le overfetching et underfetching de REST deviennent douloureux. GraphQL permet au client de décrire exactement ce dont il a besoin et de recevoir précisément ça, ni plus ni moins.
La contrepartie de GraphQL est sa complexité opérationnelle : gestion de la complexité des requêtes (query depth limiting), observabilité plus difficile, caching moins naturel. Le N+1 problem est un piège classique si on ne configure pas correctement les DataLoaders. Une règle empirique : si vous avez un seul client frontend que vous maîtrisez et des besoins de données stables, REST suffit largement. Si vous exposez une API à de nombreux clients avec des besoins hétérogènes, GraphQL vaut l'investissement.