écrits
Architecture· Mai 2026· Lecture · 10 min

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 ?

APIApplication 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.

Les trois questions qui rangent tout
Qui initie ?
Client demande
Serveur pousse
Les deux en duplex
Combien de temps ?
One-shot (requête / réponse)
Persistant (connexion ouverte)
Streaming (flux continu)
Quel format ?
Texte (JSON, XML)
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.

Transport
HTTP/1.1 ou HTTP/2
Format
JSON (souvent), texte
Pattern
Requête → réponse
Récupérer un utilisateur
GET /api/users/42 → 200 OK { "id": 42, "name": "Alice", "email": "alice@example.com" }
Forces
  • Universellement supporté, cacheable nativement
  • Conventions claires, courbe d'apprentissage douce
  • Outillage abondant (curl, Postman, navigateurs)
Limites
  • Over-fetching et under-fetching fréquents
  • Pas de streaming natif, pas de push serveur
  • Versioning des contrats parfois douloureux
À utiliser pour API publiques web, CRUD applicatif, intégrations tierces, mobile classique. Quand on hésite, c'est le défaut raisonnable.

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.

Transport
HTTP, SMTP, TCP, JMS…
Format
XML strict + WSDL
Pattern
Requête → réponse
Enveloppe SOAP minimale
POST /UserService Content-Type: text/xml <soap:Envelope xmlns:soap="..."> <soap:Body> <GetUser> <UserId>42</UserId> </GetUser> </soap:Body> </soap:Envelope>
Forces
  • Contrats stricts via WSDL, génération de clients
  • Sécurité robuste (WS-Security, signatures XML)
  • Support natif des transactions distribuées
Limites
  • Verbosité XML énorme (overhead réseau et CPU)
  • Outillage moderne plus rare, courbe raide
  • Mal adapté au web mobile et aux navigateurs
À utiliser pour Systèmes legacy d'entreprise, intégrations bancaires, paiements interbancaires, secteurs réglementés. Rarement un choix de greenfield aujourd'hui.

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.

Transport
HTTP/2 (requis)
Format
Protocol Buffers (binaire)
Pattern
Unary + 3 modes streaming
Contrat .proto
syntax = "proto3"; service UserService { rpc GetUser(UserId) returns (User); rpc StreamUsers(Filter) returns (stream User); } message User { int32 id = 1; string name = 2; }
Forces
  • Payload 5 à 10× plus compact que JSON
  • Streaming bidirectionnel natif
  • Génération de clients typés multi-langages
Limites
  • Support navigateur partiel (passe par gRPC-Web)
  • Debug binaire moins direct que JSON
  • Exige HTTP/2 de bout en bout
À utiliser pour Microservices internes haute performance, communication inter-datacenters, environnements polyglottes avec contrats stricts. Le défaut chez Google, Netflix, Square.

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.

Transport
HTTP (souvent POST)
Format
Query language + JSON
Pattern
Requête déclarative
Requête GraphQL
query { user(id: 42) { name posts(last: 3) { title comments { author } } } }
Forces
  • Plus d'over-fetching, une seule requête réseau
  • Schéma typé, introspection, outillage riche
  • Évolution sans versioning de l'API
Limites
  • Caching HTTP standard inopérant
  • Problème du N+1 côté résolveurs
  • Complexité backend, risque de requêtes coûteuses
À utiliser pour Frontends complexes avec besoins de données variables (apps mobile + web partageant un backend), agrégation de plusieurs services, BFF (Backend For Frontend).

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.

Transport
HTTP (POST entrant)
Format
JSON (souvent signé HMAC)
Pattern
Serveur → client (push)
Webhook Stripe entrant
POST https://mon-app.com/webhooks/stripe Stripe-Signature: t=1715..., v1=a4f7b2... { "type": "payment_intent.succeeded", "data": { "amount": 4200, "customer": "cus_xyz" } }
Forces
  • Quasi temps réel sans polling
  • Découplage propre entre producteur et consommateur
  • Économise une énorme charge serveur
Limites
  • Endpoint public requis (NAT, firewall, tunnel)
  • Signature obligatoire (HMAC) sinon falsifiable
  • Retries et idempotence à la charge du consommateur
À utiliser pour Événements paiement (Stripe), CI/CD (GitHub Actions, GitLab), notifications de messageries, intégrations Zapier-like. Toute architecture event-driven inter-systèmes.

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.

Transport
TCP (via upgrade HTTP)
Format
Libre (texte ou binaire)
Pattern
Full-duplex persistant
Handshake puis dialogue
// 1. Upgrade HTTP → WebSocket GET /chat HTTP/1.1 Upgrade: websocket Connection: Upgrade // 2. Dialogue libre dans les deux sens client → {"msg": "Salut tout le monde"} server → {"users_online": 42} server → {"msg": "Bob a rejoint"} client → {"typing": true}
Forces
  • Latence très faible, pas de re-handshake
  • Le serveur peut pousser à tout moment
  • Support navigateur natif depuis longtemps
Limites
  • Connexions stateful : scaling horizontal complexe
  • Reconnexion à gérer côté client
  • Proxies et load balancers parfois récalcitrants
À utiliser pour Chat temps réel, notifications push, jeux multijoueurs, tableaux de bord live, édition collaborative (Google Docs, Figma), flux financiers.

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.

Transport
UDP (SRTP, SCTP, DTLS)
Format
Media + binaire arbitraire
Pattern
Pair-à-pair temps réel
Établissement d'une session
// 1. Signaling (via serveur tiers) const pc = new RTCPeerConnection(); const offer = await pc.createOffer(); signalingServer.send(offer); // → pair distant // 2. Pair distant répond avec sa SDP pc.setRemoteDescription(answer); // 3. Le flux media va directement P2P pc.ontrack = (event) => videoEl.srcObject = event.streams[0];
Forces
  • Latence ultra-faible (~100ms perçue)
  • P2P : économise une énorme bande passante serveur
  • Chiffrement end-to-end imposé par la spec
Limites
  • Complexité du signaling, STUN, TURN à opérer
  • P2P pur ne scale pas au-delà de quelques pairs (SFU)
  • Debug et observabilité difficiles
À utiliser pour Visioconférence (Meet, Zoom), appels audio in-app, streaming live faible latence, transferts P2P de fichiers, jeux en cloud.

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
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.
En une phrase

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.