Les sept familles d'API

D'abord, c'est quoi une API ?

API veut dire Application Programming Interface. C'est le contrat qui permet à un programme d'en utiliser un autre sans connaître ses détails internes. Ce contrat peut être une bibliothèque appelée en mémoire, un service local exposé sur une socket ou, ce qui nous intéresse ici, un système distant joint par le réseau.

La suite parle donc des API réseau, où deux machines échangent des données ou déclenchent des opérations à distance selon un protocole défini. Les sept familles ci-dessous se distinguent par ce protocole.

Trois axes pour s'orienter

Comparer ces protocoles sur leur popularité ou leur âge ne mène pas loin. Chacun répond à un problème de communication, et trois questions suffisent à les séparer.

Vus sous ces trois angles, ce ne sont plus sept protocoles concurrents. GraphQL et REST sont proches voisins, WebRTC est loin des deux, et c'est pour cela qu'on ne remplace pas l'un par l'autre.

REST, le standard de facto

REST n'est pas un protocole mais un style d'architecture, décrit par Roy Fielding dans sa thèse en 2000. Tout y est une ressource identifiée par une URL. Le style ne dépend pas de HTTP, mais les API dites RESTful manipulent ces ressources avec les verbes HTTP (GET, POST, PUT, PATCH, DELETE), et la plupart ignorent la contrainte d'hypermédia (HATEOAS) de Fielding. Chaque requête est stateless : le serveur ne garde aucun contexte de session entre deux appels. Les ressources vivent bien côté serveur, c'est la conversation qui est sans mémoire.

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

Mon avis. Pour une nouvelle app SaaS B2B, 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 est un protocole strict basé sur XML. Le nom voulait dire Simple Object Access Protocol, mais depuis la version 1.2 (2003) ce n'est plus un acronyme. Son contrat formel, le WSDL, décrit chaque opération et chaque type de données. On se moque souvent de sa verbosité, pourtant il reste en place dans la banque, l'assurance, la défense et les systèmes qui ont besoin de transactions distribuées entre applications.

enveloppe XML lourde, contrat WSDL strict

gRPC, la performance pour le back-to-back

gRPC est le framework RPC ouvert par Google en 2015. Il combine trois choix techniques : Protocol Buffers comme format binaire compact, HTTP/2 comme transport (multiplexage, streams, compression d'en-têtes), et la génération de code à partir d'un fichier .proto dans la plupart des langages. On obtient des appels typés et rapides, avec du streaming dans les deux sens.

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

Mon avis. gRPC seulement si l'organisation sait opérer Protobuf : codegen intégré au CI, breaking changes versionnés avec rigueur, outillage de debug binaire en place. Sinon on gagne en performance et on perd en productivité.

GraphQL, le client décide ce qu'il veut

GraphQL (Facebook, publié en 2015) donne la main au client. Au lieu d'une liste figée d'endpoints, le serveur publie un schéma typé, et le client y décrit exactement les champs dont il a besoin, en une seule requête. Plus besoin d'enchaîner GET /user, GET /user/posts puis GET /user/posts/comments.

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

Mon avis. Souvent trop lourd 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

Avec un webhook, c'est le service tiers qui appelle. On lui donne une URL, et quand un événement survient chez lui (paiement réussi, commit poussé, message reçu), il envoie une requête HTTP vers cette URL. Plus besoin de demander toutes les cinq secondes s'il y a du nouveau : on est prévenu au moment où ça 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. D'où 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, les 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 une visio à plus de deux participants passe en pratique par un SFU (Selective Forwarding Unit) côté serveur. Le pair-à-pair pur reste l'exception.

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

Mon avis. Le P2P gratuit n'existe pas en production. Entre TURN à provisionner, un SFU dimensionné pour les appels à plus de deux et une équipe pour observer la pile WebRTC, le coût d'exploitation approche celui d'un serveur de streaming classique. On le choisit quand la latence l'impose, rarement par défaut.

La matrice de décision

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

Si tu dois décider demain