Choisissez en fonction de qui consomme l'API et de la diversité de ses besoins en données — pas selon la mode. GraphQL l'emporte quand de nombreux clients variés doivent façonner leurs propres données ; REST l'emporte quand les requêtes sont uniformes, cachables et simples.
user -> posts -> comments) au lieu de N allers-retours REST.GET de REST se cache trivialement à chaque couche ; GraphQL a besoin de persisted queries pour s'en approcher.| Aspect | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Résolu par conception | Problème courant |
| Caching HTTP/CDN | Difficile (demande du travail) | Natif et facile |
| Contrôle coût des requêtes/DoS | À ajouter soi-même | Naturellement borné |
| Flexibilité client | Élevée | Faible |
| Complexité serveur | Plus élevée | Plus faible |
Les deux ne s'excluent pas non plus — beaucoup de systèmes exposent du REST pour les endpoints publics/cachables et du GraphQL pour les clients internes riches.
Les recruteurs seniors testent le jugement, pas l'allégeance. La réponse forte nomme les axes — diversité des clients, besoins de caching, maturité de l'équipe, surface de DoS — et admet les coûts réels de GraphQL (caching et contrôle du coût des requêtes) au lieu de le vendre comme universellement meilleur.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don