Quel style d'API pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas le style le plus moderne, mais la forme de l'échange : requête/réponse, requêtes variables, interne haute perf, ou temps réel.
Pars de REST pour une API publique ou simple. Passe à GraphQL si le client a des besoins de requêtes très variables, à gRPC pour la communication interne entre services, à WebSocket seulement s'il faut du temps réel bidirectionnel.
REST / requête/réponse HTTP
Le défaut. Simple, universel, bien outillé.
Choisir si : API publique, besoin de cache HTTP natif, clients variés (web, mobile, tiers).
Éviter si : besoin de requêtes très imbriquées → over-fetching/under-fetching fréquent.
GraphQL / requête déclarative
Le client demande exactement ce qu'il veut.
Choisir si : clients aux besoins hétérogènes (web/mobile), données fortement imbriquées, éviter le over-fetching.
Éviter si : cache HTTP simple, équipe sans temps pour gérer la complexité des resolvers/N+1.
gRPC / RPC binaire
La performance entre services.
Choisir si : communication interne microservices, contrats stricts (protobuf), streaming bidirectionnel performant.
Éviter si : API publique consommée directement par un navigateur — support limité sans passerelle.
WebSocket / connexion bidirectionnelle
Le serveur peut parler en premier.
Choisir si : temps réel (chat, notifications live, collaboratif), connexion persistante nécessaire.
Éviter si : échanges ponctuels classiques → une simple requête REST suffit et coûte moins cher en infra.
Webhooks / notification événementielle
Ne demande pas, on te préviendra.
Choisir si : intégrations tierces, événements peu fréquents, découpler un service qui notifie plutôt que d'être interrogé.
Éviter si : besoin de réponse immédiate/synchrone, communication interne à faible latence.