Les 7 familles d'API, sans l'amalgame

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.

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 au sens où le serveur ne garde aucun contexte de session entre deux appels — l'état des ressources reste évidemment côté serveur, c'est la conversation client-serveur qui est sans mémoire.

requête → réponse, sans état partagé

Mon angle d'ingénieur : dans une app SaaS B2B greenfield, je commence presque toujours par REST. Le coût d'entrée est nul, l'outillage suit, et le jour où une portion du trafic exige réellement du streaming ou de l'agrégation côté client, on ajoute la techno qui répond — gRPC sur un sous-chemin interne, GraphQL sur un BFF — sans tout réécrire.

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.

enveloppe XML lourde, contrat WSDL strict

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.

frames binaires multiplexés sur HTTP/2, streaming bidirectionnel

Mon angle d'ingénieur : gRPC seulement quand l'organisation sait opérer Protobuf — codegen intégré au CI, breaking changes versionnés discipline-de-fer, outillage de debug binaire en place. Sans ça, on récupère la performance et on perd la productivité.

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.

une requête déclarative, une réponse de forme identique

Mon angle d'ingénieur : souvent overkill pour une seule appli web. La valeur de GraphQL apparaît quand plusieurs frontends différents tapent le même backend — sinon, on paie la complexité serveur sans en récolter les bénéfices.

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.

le serveur déclenche, votre endpoint reçoit

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.

une connexion ouverte, du trafic libre dans les deux sens

WebRTC, le pair-à-pair temps réel

WebRTC permet à deux navigateurs (ou applications) d'établir une connexion directe de pair à pair dans le cas idéal. Le serveur intervient pour la phase de signaling — échanger les descriptions de session (SDP) — et pour la traversée NAT (STUN, puis TURN si STUN échoue). En conditions réelles, TURN relaie souvent le trafic quand le NAT bloque la connexion directe, et toute visio à plus de deux participants passe en pratique par un SFU (Selective Forwarding Unit) côté serveur. Le « pur P2P » est un cas limite, pas la règle.

phase 1 — signaling SDP, phase 2 — flux direct entre pairs

Mon angle d'ingénieur : le « P2P gratuit » est un mirage en production. Sitôt qu'il faut TURN provisionné, un SFU dimensionné pour les calls à plus de deux, et une équipe pour observer la WebRTC stack, le coût opérationnel approche celui d'un serveur de streaming classique. C'est rarement le choix par défaut — c'est celui de la latence ultra-faible imposée.

La matrice de décision

Tout ramener à une question pratique : qu'est-ce que je veux faire ?

Si tu dois décider demain