Partir des cas d'usage
Le bon style d'API est celui qui colle a vos besoins. REST est parfait pour des ressources et du CRUD. GraphQL est utile quand les clients ont des vues diverses. RPC est naturel pour les actions et workflows.
Commencer par une mode au lieu des contraintes produit est un risque.
REST : previsible et compatible
REST s'aligne sur HTTP, ce qui facilite le cache, le logging et le debug. L'ecosysteme web comprend REST par defaut.
La limite est la flexibilite : si un client veut une vue custom, REST demande plus d'endpoints ou des parametres.
GraphQL : flexible mais plus lourd
GraphQL permet aux clients de demander exactement les champs necessaires. Cela peut reduire la bande passante.
Mais cela ajoute de la complexite serveur : resolvers, schema, cache et risques de performance.
RPC : clair pour les actions
RPC est efficace quand l'API est une liste de commandes : `RunReport`, `SyncDevices`. Pas besoin de forcer la ressource.
En contrepartie, on perd les benefices natifs d'HTTP. Il faut definir ses propres conventions.
Performance et cache
REST tire parti du cache HTTP. GraphQL/RPC demandent souvent un cache sur mesure.
Si la lecture est critique, REST est plus simple a optimiser. Si la flexibilité prime, GraphQL peut valoir le cout.
Erreurs et observabilite
REST utilise les codes HTTP. GraphQL/RPC mettent souvent les erreurs dans le body. Cela change le monitoring.
Si vous vous basez sur les status, REST est plus direct. Sinon, ajoutez des metriques d'erreurs explicites.
Quand un hybride est pertinent
Beaucoup de systemes mixent : REST pour les ressources, RPC pour les actions, GraphQL pour l'agregation. C'est valide si les frontieres sont claires.
Le danger est le melange sans regle. Definissez ou chaque style est autorise.
Guide de decision
REST pour la simplicite et le cache. GraphQL pour des vues clients variees. RPC pour des workflows non orientés ressources.
Commencez simple : ajouter un second style plus tard est souvent plus sain.