​

REST (Representational State Transfer)

• Sans État (Stateless) : Chaque requête du client au serveur doit contenir toutes les informations nécessaires à la compréhension de la requête. Le serveur n’enregistre aucune information de session spécifique au client entre les requêtes.
• Client-Serveur : Séparation claire entre l’interface utilisateur (client) et le stockage de données (serveur).
• Mise en Cache (Cacheable) : Les réponses doivent déclarer si elles sont cacheables pour améliorer les performances.
• Interface Uniforme : Utilisation d’URI pour identifier les ressources et de méthodes HTTP standard pour les actions.

• Standard du Web : REST est le standard de facto pour les API Web publiques, ce qui assure une grande interopérabilité.
• Simplicité : Facile à comprendre, à mettre en œuvre et à tester grâce aux méthodes HTTP.
• Mise en Cache Naturelle : Utilise la mise en cache HTTP native pour les requêtes GET.

• Sur-Extraction (Over-Fetching) : Le client reçoit souvent plus de données que nécessaire, car le serveur envoie la représentation complète de la ressource.
• Sous-Extraction (Under-Fetching) : Le client doit parfois faire plusieurs requêtes successives (par exemple, obtenir une liste de commandes, puis faire une requête pour chaque article dans la commande) pour obtenir toutes les données connexes.
• Granularité Fixe : La structure des données retournées est fixée par le serveur.

• JSON (le plus courant) ou XML.

​

GraphQL (Graph Query Language)

• Schéma Fort (Schema) : L’API est définie par un schéma de types (Strongly Typed Schema) que le client peut interroger (via une requête Query) ou modifier (via une requête Mutation).
• Une Seule URL : Toutes les requêtes sont envoyées à la même URL, généralement via une requête POST.
• Filtre Côté Client : Le client ne reçoit que les champs explicitement demandés.

• Flexibilité et Efficacité : Élimine le Over-Fetching et le Under-Fetching. Le client reçoit uniquement les données exactes nécessaires.
• Réduction des Requêtes : Permet de récupérer plusieurs ressources connexes en une seule requête au lieu de multiples requêtes REST.
• Développement Front-end Rapide : Permet au frontend d’itérer rapidement sans attendre que le backend modifie les structures de réponse.

• Complexité de Mise en Cache : La mise en cache HTTP standard est difficile, car toutes les requêtes sont des POSTs vers la même URL.
• Complexité Serveur : Le développement du résolveur (resolver) côté serveur est plus complexe, car il doit gérer la logique d’extraction de données pour chaque champ possible.
• Sécurité et Limites de Débit : Plus difficile à sécuriser et à limiter (rate limit) que REST.

• JSON.

​

gRPC (Google Remote Procedure Call)

• HTTP/2 : Utilise les fonctionnalités d’HTTP/2 comme le multiplexage (plusieurs requêtes sur une seule connexion) et la compression des en-têtes.
• Protocol Buffers (Protobuf) : Utilise un format de sérialisation binaire efficace (plus rapide et plus petit que JSON), défini via un fichier IDL (Interface Definition Language).
• Streaming : Supporte nativement le streaming bidirectionnel et unidirectionnel.

• Performance Exceptionnelle : La sérialisation binaire de Protobuf et HTTP/2 rendent gRPC beaucoup plus rapide et efficace en bande passante que REST ou GraphQL.
• Typage Strict : L’utilisation de Protobuf assure une forte cohérence entre le client et le serveur (typage fort).
• Multi-Langage : Les fichiers Protobuf peuvent générer le code client et serveur dans pratiquement n’importe quel langage de programmation.

• Moins lisible : Les données binaires sont illisibles par l’humain sans désérialisation, rendant le débogage plus difficile.
• Support Navigateur : Non nativement supporté par les navigateurs web modernes (nécessite un proxy comme gRPC-Web).
• Pas le standard Web : Principalement utilisé pour la communication de service à service (service-to-service).

• Protocol Buffers (Format binaire).

​

WebSockets

• Handshake (Poignée de main) : La connexion commence par un handshake HTTP standard (passage de http:// à ws:// ou https:// à wss://), puis la connexion passe au protocole WebSocket.
• Full-Duplex : Le serveur et le client peuvent envoyer des données indépendamment à tout moment.
• Faible Latence : Une fois la connexion établie, il n’y a plus la surcharge des en-têtes HTTP répétitifs.

• Temps Réel : Permet la diffusion instantanée des données du serveur au client sans que le client ait besoin de poller (interroger périodiquement) le serveur.
• Faible Surcharge : Une fois la connexion établie, la surcharge de transmission est minime.

• Complexité de Mise à l’Échelle : Maintenir des milliers de connexions persistantes sur les serveurs nécessite une architecture de load balancing spécifique (stickiness).
• Débogage : Peut être plus complexe à déboguer que les simples requêtes HTTP.

• Chats en direct, notifications en temps réel, jeux multijoueurs.
• Flux de données financiers ou sportifs.

​

Tableau Comparatif des Styles d’API