Les 7 familles d'API, sans l'amalgame
REST, SOAP, gRPC, GraphQL, Webhooks, WebSockets, WebRTC. Sept manières de faire communiquer deux machines. Aucune n'est meilleure que les autres : chacune répond à un problème précis. Voici la grille de lecture.
D'abord, c'est quoi une API ?
API — Application Programming Interface. Un contrat technique qui permet à un programme d'en utiliser un autre, sans connaître ses détails internes. La nature du contrat varie : une bibliothèque appelée en mémoire, un service local exposé sur une socket, ou — le cas qui nous intéresse ici — un système distant accessible via le réseau.
Tout ce qui suit concerne donc les API réseau : deux machines distinctes qui s'échangent des données ou déclenchent des opérations à distance, à travers un protocole défini. Et c'est justement le choix de ce protocole qui ouvre les sept familles ci-dessous.
Trois axes pour s'orienter
L'erreur la plus fréquente, c'est de comparer ces protocoles sur leur popularité ou leur âge. Une API n'est pas un produit : c'est une réponse à un problème de communication. Avant de regarder les sept familles, il faut poser les axes qui les séparent vraiment.
Serveur pousse
Les deux en duplex
Persistant (connexion ouverte)
Streaming (flux continu)
Binaire (Protobuf)
Media (audio/vidéo)
Avec ces trois axes en tête, on cesse de voir « sept protocoles concurrents » pour voir « sept points dans un espace ». GraphQL et REST sont proches voisins. WebRTC vit dans une autre galaxie. C'est pour ça qu'on ne les remplace pas l'un par l'autre.
REST, le standard de facto
REST n'est pas un protocole, c'est un style architectural posé par Roy Fielding dans sa thèse. L'idée centrale : tout est une ressource identifiée par une URL, manipulée via les verbes HTTP standards (GET, POST, PUT, DELETE). Chaque requête est stateless : le serveur ne garde aucun contexte entre deux appels.
- Universellement supporté, cacheable nativement
- Conventions claires, courbe d'apprentissage douce
- Outillage abondant (curl, Postman, navigateurs)
- Over-fetching et under-fetching fréquents
- Pas de streaming natif, pas de push serveur
- Versioning des contrats parfois douloureux
SOAP, le vétéran de l'entreprise
SOAP (Simple Object Access Protocol) est un protocole strict basé sur XML, doté d'un contrat formel (le WSDL) qui décrit chaque opération et chaque type de données. C'est l'ancêtre des API modernes — souvent moqué pour sa verbosité, mais toujours en place dans la banque, l'assurance, la défense, et tout ce qui demande des transactions ACID inter-systèmes.
- Contrats stricts via WSDL, génération de clients
- Sécurité robuste (WS-Security, signatures XML)
- Support natif des transactions distribuées
- Verbosité XML énorme (overhead réseau et CPU)
- Outillage moderne plus rare, courbe raide
- Mal adapté au web mobile et aux navigateurs
gRPC, la performance pour le back-to-back
gRPC est le framework RPC moderne issu de Google. Il combine trois choix techniques : Protocol Buffers comme format binaire compact, HTTP/2 comme transport (multiplexage, push, compression d'en-têtes), et la génération de code à partir d'un fichier .proto dans la plupart des langages. Résultat : des appels typés, rapides, qui supportent le streaming dans les deux sens.
- Payload 5 à 10× plus compact que JSON
- Streaming bidirectionnel natif
- Génération de clients typés multi-langages
- Support navigateur partiel (passe par gRPC-Web)
- Debug binaire moins direct que JSON
- Exige HTTP/2 de bout en bout
GraphQL, le client décide ce qu'il veut
GraphQL (Facebook, 2015) inverse le contrôle de la donnée. Plutôt qu'une liste figée d'endpoints, le serveur publie un schéma typé, et le client interroge ce schéma en décrivant exactement les champs dont il a besoin, le tout en une seule requête. Fini les GET /user, puis GET /user/posts, puis GET /user/posts/comments : tout tient en une expression déclarative.
- Plus d'over-fetching, une seule requête réseau
- Schéma typé, introspection, outillage riche
- Évolution sans versioning de l'API
- Caching HTTP standard inopérant
- Problème du N+1 côté résolveurs
- Complexité backend, risque de requêtes coûteuses
Webhooks, l'API inversée
Un webhook n'est pas une API qu'on appelle, c'est une API qui appelle. Le principe : fournir une URL à un service tiers ; quand un événement survient chez lui (un paiement réussi, un commit poussé, un message reçu), il envoie une requête HTTP vers cette URL. C'est l'antidote au polling : plutôt que de demander toutes les cinq secondes « du nouveau ? », le système est notifié au moment où l'événement se produit.
- Quasi temps réel sans polling
- Découplage propre entre producteur et consommateur
- Économise une énorme charge serveur
- Endpoint public requis (NAT, firewall, tunnel)
- Signature obligatoire (HMAC) sinon falsifiable
- Retries et idempotence à la charge du consommateur
WebSockets, le tunnel bidirectionnel
WebSocket ouvre une connexion TCP persistante et bidirectionnelle entre client et serveur, après un handshake HTTP initial qui « upgrade » la connexion. Une fois établie, les deux côtés peuvent émettre des messages à tout moment, sans nouveau cycle requête-réponse. C'est ce qui permet le chat temps réel, les flux de marché, l'édition collaborative.
- Latence très faible, pas de re-handshake
- Le serveur peut pousser à tout moment
- Support navigateur natif depuis longtemps
- Connexions stateful : scaling horizontal complexe
- Reconnexion à gérer côté client
- Proxies et load balancers parfois récalcitrants
WebRTC, le pair-à-pair temps réel
WebRTC permet à deux navigateurs (ou applications) d'établir une connexion directe de pair à pair, sans relais serveur pour les données utiles. Le serveur n'intervient que pour la phase de signaling : échanger les descriptions de session (SDP) et traverser les NAT (STUN/TURN). Une fois la connexion établie, la voix, la vidéo et les DataChannels binaires circulent directement entre les pairs.
- Latence ultra-faible (~100ms perçue)
- P2P : économise une énorme bande passante serveur
- Chiffrement end-to-end imposé par la spec
- Complexité du signaling, STUN, TURN à opérer
- P2P pur ne scale pas au-delà de quelques pairs (SFU)
- Debug et observabilité difficiles
La matrice de décision
Tout ramener à une question pratique : qu'est-ce que je veux faire ?
| Si l'objectif est… | Le bon choix | Pourquoi |
|---|---|---|
| Exposer une API publique | REST | Universel, cacheable, attendu par les intégrateurs |
| Communiquer entre microservices internes | gRPC | Compact, typé, streaming, multi-langages |
| Servir un frontend mobile + web complexe | GraphQL | Évite l'over-fetching, une requête par écran |
| Réagir à des événements externes | Webhooks | Pas de polling, découplage propre |
| Chat, notifications, dashboards live | WebSockets | Bidirectionnel persistant, faible latence |
| Audio / vidéo / data en temps réel | WebRTC | Pair-à-pair, latence minimale, media-natif |
| S'intégrer à un système bancaire legacy | SOAP | Contrats stricts, sécurité éprouvée, déjà en place |
REST pour le web ouvert, gRPC pour le back-to-back interne, GraphQL pour les frontends gourmands, Webhooks pour réagir, WebSockets pour dialoguer, WebRTC pour le temps réel media, SOAP pour le legacy d'entreprise. Aucune n'est obsolète : chacune répond à un problème spécifique.