Comment choisir entre REST et GraphQL (ou mixer les deux)

Après avoir posé les bases de REST et de GraphQL, et regardé leurs impacts sur les perfs, il reste la question qui compte vraiment :
que dois‑tu utiliser pour ton prochain projet, et comment éviter les regrets dans 2 ans ?

1. Quelques questions clés à te poser

Avant de parler outils, pose le contexte :

• Taille et maturité de l’équipe : 2 devs full‑stack n’ont pas les mêmes besoins qu’une équipe avec plusieurs squads front/back.
• Type de clients : front web riche, applications mobiles, intégrations B2B, partenaires externes, etc.
• Stabilité du domaine métier : modèle encore mouvant ou déjà bien stabilisé.
• Contraintes non fonctionnelles : SLA, coûts, conformité, exposition publique ou non.

Ces éléments influencent directement la pertinence d’introduire (ou non) GraphQL.

2. Quand REST est un no‑brainer

REST est souvent le meilleur choix lorsque :

• Tu exposes une API simple (CRUD, ressources bien identifiées).
• Tu adresses des intégrations B2B ou des partenaires externes qui s’attendent à du REST.
• Tu as une petite équipe qui ne veut pas investir tout de suite dans du tooling GraphQL.
• Le frontend n’a pas des besoins de composition de données très complexes.

En pratique, beaucoup de projets peuvent vivre très longtemps avec :

• Une API REST bien conçue.
• Une bonne doc (OpenAPI), des exemples, un contrat d’erreurs propre.
• Un minimum de gouvernance de versioning (breaking changes maîtrisées).

3. Quand GraphQL fait vraiment la différence

GraphQL devient intéressant quand :

• Tu as plusieurs clients front (web, mobile, partenaires) qui consomment des vues très différentes des mêmes données.
• Tes écrans sont très composites (beaucoup de sections, widgets, agrégats).
• Tes équipes front ont besoin de gagner en autonomie sur la forme des données.
• Tu veux bâtir un BFF pour cacher la complexité d’un paysage de microservices REST existants.

Dans ces cas‑là :

• GraphQL réduit le nombre de endpoints « spécialisés écran ».
• Le schéma devient un contrat unique autour duquel front et back collaborent.

4. Stratégie mixte : REST interne, GraphQL en façade

Une approche très répandue :

• Conserver les microservices internes en REST (voire gRPC).
• Ajouter une couche GraphQL au dessus qui :
• Agrège les données pour les frontends.
• Expose un schéma orienté expérience utilisateur, pas orienté backend.

Avantages :

• Tu ne jettes pas l’existant.
• Tu peux introduire GraphQL progressivement sur certains parcours uniquement.

Points de vigilance :

• Bien gérer la gouvernance du schéma (qui change quoi, comment, review).
• Ne pas transformer le serveur GraphQL en gros monolithe de glue code ingérable.

5. Transition progressive : de REST vers GraphQL (ou inversement)

Si tu as déjà une API REST en prod :

• Commence par cartographier les endpoints réellement utilisés par les frontends.
• Identifie les écrans qui souffrent le plus (nombre de requêtes, complexité, temps de dev).
• Introduis GraphQL :
• Pour un ensemble limité de parcours (ex. dashboard, profil utilisateur).
• En gardant REST pour le reste.

Si au contraire tu as commencé par GraphQL et que tu regrettes :

• Rien n’empêche de :
• Geler le schéma actuel.
• Introduire progressivement des endpoints REST spécialisés pour certains usages ou partenaires.

L’idée clé : tu n’es pas marié à vie avec un seul style.

6. Grille de décision rapide

• Front simple, peu de composition de données → REST.
• Intégrations B2B, API publique → REST, éventuellement avec quelques endpoints agrégés.
• Front riche (SPA/mobile) avec beaucoup d’écrans composites → GraphQL ou BFF GraphQL.
• Paysage microservices REST déjà en place → REST interne + couche GraphQL d’agrégation.
• Équipe réduite, peu de temps pour le tooling → REST, puis GraphQL plus tard si un vrai besoin apparaît.

7. Message de fin : pas de guerre de religion

REST et GraphQL sont des outils complémentaires :

• REST reste un excellent standard pour les ressources, l’intégration et la simplicité opérationnelle.
• GraphQL brille quand tu as besoin de flexibilité côté client et de composition de données complexes.

Le bon choix n’est pas celui qui est le plus « hype », mais celui qui réduit la friction entre ton domaine métier, tes équipes, tes utilisateurs et ton infra.
Si cette série t’a aidé à clarifier ce choix, tu peux maintenant concevoir tes APIs avec un peu plus de sérénité.