Protocols
REST, SOAP, gRPC, GraphQL, webhooks, SSE, events: what each protocol changes in the contract, and what the gateway can really do with it.
Choosing a protocol is a choice of contract and of operations, not a style preference. Each protocol changes what the gateway can verify, protect and document, and that is the angle taken here.
| Protocol | Contract | Typical use case | What the gateway can do with it |
|---|---|---|---|
| REST, JSON | OpenAPI | The default, internal as much as external | Everything: validation, quotas, cache, documentation |
| SOAP | WSDL | Legacy, interbank, public administration | Route it, convert it to REST at the edge |
| gRPC | Protobuf | High-volume internal traffic, streaming | Varies: some do not route it at all, to be checked |
| GraphQL | GraphQL schema | Client-driven aggregation | Little, with no dedicated protections |
| Webhooks | OpenAPI, outbound direction | Notify external consumers | Sign, replay, track failures |
| SSE, WebSocket | OpenAPI 3.2 for SSE, AsyncAPI for WebSocket | Real time, streamed model responses | Authenticate on open, cap the duration |
| Events | AsyncAPI | Kafka, MQTT, continuous data integration | See the three gateways |
What matters, protocol by protocol
REST remains the default because its ecosystem is complete: contract tooling, generated documentation, validation at the gateway, HTTP cache. Departing from it is justified by a measured need, not by a preference.
SOAP is not fought, it is wrapped. The systems that speak it work and will not be rewritten. Converting to REST at the edge is a legitimate case of mediation, as long as the translation stays mechanical. Beyond that, it is a facade service.
gRPC earns its place through the Protobuf contract and HTTP/2: strict typing, small messages, bidirectional streaming. Its home ground is high-volume internal traffic and calls between services. Externally, gRPC to JSON transcoding at the gateway serves both audiences with a single implementation, and that is a feature to verify with the vendor, not to assume.
GraphQL moves composition to the client, which changes the cost model: one call can cost a thousand times more than another, and limiting per call loses its meaning. Without a maximum depth, cost analysis and persisted queries, public exposure is reckless. The detail is in access.
Webhooks invert responsibility: the platform becomes the caller. Three requirements follow. Signing deliveries, so the recipient can verify provenance. Redelivery, with an idempotency key. And a table of failures per recipient: a partner whose receiving endpoint was down for an hour has to be able to replay.
SSE has established itself for streamed responses, model responses in particular: simple, unidirectional, compatible with HTTP infrastructure. WebSocket keeps the bidirectional case. For the gateway, these long-lived connections change the accounting: the relevant limit becomes the number of concurrent connections and their duration, no longer the number of calls.
The common trap
Crossing from one protocol to another almost always changes the semantics along with the form: a queue whose delivery guarantee depends on the broker, behind an API that implies a different one, a stream turned into polling, a synchronous call in front of deferred processing. The crossing is documented in the contract, delivery guarantees and idempotency keys included. Hiding it moves the cost to the consumer, where it is paid in data defects.
Updated August 2026.