Request-Response API Styles: REST vs gRPC vs GraphQL vs SOAP

Despite years of "X is dead" predictions, none of the major API styles has actually died — SOAP still runs regulated industries, REST dominates public APIs, GraphQL powers modern frontends, and gRPC handles internal service-to-service calls. I wrote up a practical comparison of all four (plus JSON-RPC) that focuses on where each one actually fits, not which one wins in the abstract. This is the short version; the full article on Medium has the complete breakdown, a decision table, and real-world scenario picks.

The Short Version

The rule of thumb I landed on: REST by default, gRPC between your own services, GraphQL when clients need to drive the data shape, and SOAP only when a counterparty or a compliance requirement forces it. REST remains the safe default for public APIs, and it just picked up a genuinely useful addition — the new HTTP QUERY method (RFC, June 2026), which lets you send complex filters in a JSON body while keeping GET's caching and idempotency guarantees, something POST could never do safely.

Why AI Agents Change the Calculus

Two constraints now matter as much as raw performance: security, since the API style shapes the attack surface, and how well AI agents can consume the API as a tool. REST with an OpenAPI spec turns out to be the clear winner here — it maps almost one-to-one onto LLM tool-calling definitions, and models trained on huge OpenAPI corpora are simply more fluent in it than in anything else. gRPC's binary Protobuf is the opposite story: unreadable to a model trying to understand an interface, but genuinely excellent for the streaming that model-serving infrastructure like vLLM actually needs. GraphQL's flexibility, meanwhile, opens a new failure mode — prompt-injection-driven query amplification, where an agent gets manipulated into generating deeply nested, expensive queries that naive depth limits alone won't stop.

Quick Picks

• Public-facing mobile app backend → GraphQL, for exact field selection over a flaky connection.
• Internal microservice-to-microservice → gRPC, for binary payloads, mTLS, and streaming.
• Legacy banking or government integration → SOAP, because WS-Security and SAML are usually a regulatory requirement, not a preference.
• Third-party public API → REST, for ubiquity, caching, and the gentlest learning curve.
• Exposing internal services as AI-agent tools → REST + OpenAPI, for the token efficiency and reliability agents need.

The full article goes through each style in depth — SOAP's WS-Security model, REST's new QUERY method and its BOLA/IDOR risk, GraphQL's depth-limiting defenses, gRPC's mTLS defaults, and where JSON-RPC still quietly wins (Ethereum nodes, the Language Server Protocol) — plus the complete decision table. Continue reading: the full article on Medium →