Les protocoles
REST, SOAP, gRPC, GraphQL, webhooks, SSE, événements : ce que chaque protocole change au contrat, et ce que la gateway sait réellement en faire.
Le choix d’un protocole est un choix de contrat et d’exploitation, pas une préférence de style. Chaque protocole change ce que la gateway peut vérifier, protéger et documenter, et c’est sous cet angle qu’ils sont présentés ici.
| Protocole | Contrat | Cas d’usage type | Ce que la gateway sait en faire |
|---|---|---|---|
| REST, JSON | OpenAPI | Le défaut, interne comme externe | Tout : validation, quotas, cache, documentation |
| SOAP | WSDL | Héritage, interbancaire, administrations | Router, convertir vers REST en périphérie |
| gRPC | Protobuf | Interne à forte volumétrie, streaming | Variable : certaines ne le routent pas du tout, à vérifier |
| GraphQL | Schéma GraphQL | Agrégation pilotée par le client | Peu, sans protections dédiées |
| Webhooks | OpenAPI, sens sortant | Notifier des consommateurs externes | Signer, rejouer, suivre les échecs |
| SSE, WebSocket | OpenAPI 3.2 pour SSE, AsyncAPI pour WebSocket | Temps réel, réponses de modèles en flux | Authentifier à l’ouverture, limiter la durée |
| Événements | AsyncAPI | Kafka, MQTT, intégration continue de données | Voir les trois gateways |
Ce qui mérite d’être su, protocole par protocole
REST reste le défaut parce que son écosystème est complet : contrat outillé, documentation générée, validation en gateway, cache HTTP. S’en écarter se justifie par un besoin mesuré, pas par une préférence.
SOAP ne se combat pas, il s’encapsule. Les systèmes qui le parlent fonctionnent et ne seront pas réécrits. La conversion vers REST en périphérie est un cas légitime de médiation, tant que la traduction reste mécanique. Au-delà, c’est un service de façade.
gRPC vaut par le contrat Protobuf et HTTP/2 : typage strict, petits messages, streaming bidirectionnel. Son terrain est l’interne à forte volumétrie et les appels entre services. En externe, le transcodage gRPC vers JSON à la gateway permet de servir les deux publics avec une seule implémentation, et c’est une fonction à vérifier chez l’éditeur, pas à supposer.
GraphQL déplace la composition chez le client, ce qui change le modèle de coût : un appel peut coûter mille fois plus qu’un autre, et la limitation par appel perd son sens. Sans profondeur maximale, analyse de coût et requêtes pré-enregistrées, l’exposition publique est imprudente. Le détail est dans accès.
Les webhooks inversent la responsabilité : la plateforme devient l’appelant. Trois exigences en découlent. La signature des livraisons, pour que le destinataire vérifie la provenance. La relivraison, avec un identifiant d’idempotence. Et un tableau des échecs par destinataire : un partenaire dont le point de réception est tombé une heure doit pouvoir se rejouer.
SSE s’est imposé pour les réponses en flux, celles des modèles notamment : simple, unidirectionnel, compatible avec l’infrastructure HTTP. WebSocket garde le bidirectionnel. Pour la gateway, ces connexions longues changent la comptabilité : la limite pertinente devient le nombre de connexions simultanées et leur durée, plus le nombre d’appels.
Le piège commun
Faire traverser un protocole à un autre change presque toujours la sémantique en même temps que la forme : une file dont la garantie de livraison dépend du courtier, derrière une API qui en laisse croire une autre, un flux devenu sondage, un appel synchrone devant un traitement différé. La traversée se documente dans le contrat, garanties de livraison et identifiants d’idempotence compris. La masquer déplace le coût chez le consommateur, où il se paie en défauts de données.
Mis à jour en août 2026.