REST vs GraphQL vs gRPC : choisir un style d'API
Trois styles d'API, trois jeux de compromis, pas de gagnant universel. Voici ce à quoi chacun est vraiment bon, ce qu'il coûte, et comment choisir, y compris en les mélangeant.
REST, GraphQL et gRPC ne sont pas des implémentations concurrentes de la même chose ; ce sont trois réponses à des problèmes différents. REST est le défaut généraliste, GraphQL résout l'agrégation de données pilotée par le client, et gRPC est fait pour une communication stricte et rapide entre services. Bien choisir, c'est savoir quel problème vous avez réellement.
REST vs GraphQL vs gRPC en un coup d'oeil
| Aspect | REST | GraphQL | gRPC |
|---|---|---|---|
| Transport / format | HTTP + JSON | HTTP + JSON (souvent un seul endpoint POST) | HTTP/2 + Protocol Buffers |
| Contrat | OpenAPI (optionnel, externe) | Schéma typé, obligatoire | Fichiers proto, obligatoires, code généré |
| Over / under-fetching | Fréquent, corrigé par paramètres ou endpoints | Le client choisit exactement les champs | Messages fixes, serrés |
| Cache HTTP | Natif (ETag, Cache-Control) | Difficile (POST), cache applicatif nécessaire | Non applicable |
| Streaming | SSE ou contournements | Subscriptions | De première classe (client, serveur, bidirectionnel) |
| Support navigateur | Natif | Natif | Nécessite grpc-web et un proxy |
| Courbe d'apprentissage | Faible | Moyenne, plus la perf des résolveurs | Moyenne, plus l'outillage et les proxies |
REST : le défaut raisonnable
REST associe des ressources à des URL et des opérations à des verbes HTTP, et vous obtenez gratuitement le cache HTTP, un immense écosystème d'outils et un modèle que tout développeur comprend déjà. Pour une API publique, un backend mobile ou une app web directe, REST bien fait (ressources, versioning, erreurs cohérentes, pagination) est la bonne réponse et les autres sont du surcoût.
GraphQL : l'agrégation pilotée par le client
GraphQL gagne sa place quand beaucoup de clients différents ont besoin de beaucoup de formes différentes des mêmes données, et que REST forcerait soit des dizaines d'endpoints, soit un lourd over-fetching. Le client demande exactement les champs dont il a besoin en une requête. Les coûts sont réels : le cache HTTP cesse en grande partie de fonctionner, les résolveurs créent des requêtes N+1 sauf si vous ajoutez du batching (DataLoader), et il vous faut des limites de profondeur et de complexité sinon une seule requête coûteuse peut faire tomber le serveur. Ça change aussi le versioning : vous dépréciez des champs plutôt que de couper une v2.
gRPC : strict, rapide, interne
gRPC utilise Protocol Buffers sur HTTP/2, avec le contrat défini dans des fichiers proto et le code client et serveur généré à partir d'eux. C'est compact, rapide, et ça supporte le streaming dans tous les sens. C'est le bon outil pour les appels service à service à l'intérieur de votre système où vous contrôlez les deux bouts et voulez un contrat serré et typé. C'est un mauvais choix pour un navigateur (il faut grpc-web et un proxy) et pour une API publique où les consommateurs attendent du JSON.
On peut les mélanger
La forme courante en production n'est pas un style partout. Une API REST ou GraphQL fait face au monde extérieur, gRPC relie les services derrière, et là où plusieurs clients ont besoin de données sur mesure, une couche GraphQL se place devant en backend-for-frontend qui agrège les appels REST et gRPC. Choisissez par frontière, pas par système.
Un guide de décision
- ✓API publique, backend mobile, app web standard : REST.
- ✓Un backend, beaucoup de clients aux besoins de données très différents, agrégation entre sources : GraphQL, et prévoyez le budget pour le cache et la perf des résolveurs.
- ✓Service à service interne, vous contrôlez les deux bouts, vous voulez un contrat typé strict et du streaming : gRPC.
- ✓Pas sûr : commencez par REST. Vous pourrez ajouter un BFF GraphQL ou du gRPC en interne plus tard sans réécrire l'API.
FAQ
- REST ou GraphQL pour une nouvelle API ?
- Commencez par REST sauf raison spécifique contraire. REST vous donne le cache HTTP, un outillage universel et un modèle familier. Choisissez GraphQL quand beaucoup de clients ont besoin de beaucoup de formes différentes des mêmes données et que REST signifierait des dizaines d'endpoints ou un lourd over-fetching, et que vous êtes prêt à gérer le cache et la perf des résolveurs.
- GraphQL remplace-t-il REST ?
- Non. Ils résolvent des problèmes différents. GraphQL est fort pour l'agrégation pilotée par le client sur beaucoup de clients ; REST est plus simple, cache nativement, et convient mieux aux API publiques et aux apps directes. Beaucoup de systèmes utilisent les deux : REST ou GraphQL en bordure, et souvent une couche GraphQL qui agrège des services REST derrière.
- Quand utiliser gRPC ?
- Pour la communication service à service à l'intérieur d'un système que vous contrôlez des deux côtés, où vous voulez un contrat typé strict, peu de surcoût et du streaming. Ce n'est pas un bon choix pour les navigateurs (il faut grpc-web et un proxy) ni pour les API publiques où les consommateurs attendent du JSON sur du HTTP simple.
- GraphQL est-il plus lent que REST ?
- Pas intrinsèquement, mais il est plus facile à rendre lent. Une requête GraphQL peut déclencher des appels N+1 en base dans les résolveurs sauf si vous ajoutez du batching, et une requête non bornée peut être très coûteuse, ce qui rend les limites de profondeur et de complexité obligatoires. REST vous pousse vers une requête par endpoint, ce qui est plus facile à raisonner.
- Peut-on utiliser GraphQL et REST ensemble ?
- Oui, et c'est courant. Un pattern fréquent : des services REST pour le coeur du domaine et un backend-for-frontend GraphQL qui les appelle et façonne la réponse pour chaque client. Vous pouvez aussi exposer les mêmes données des deux façons, même si maintenir deux contrats est un travail supplémentaire.
REST, GraphQL et gRPC sont des outils pour des frontières différentes : la bordure publique, la couche d'agrégation client, et le maillage interne. La plupart des systèmes qui choisissent bien en utilisent plus d'un. Dans le doute, REST est le point de départ sûr, et les autres sont des ajouts que vous faites quand un besoin précis apparaît.
Besoin d'aide sur ce sujet ? Conception d'API REST
Découvrir ce service →