REST vs GraphQL vs gRPC vs SOAP — how do you actually choose?

#Four different bets about where the friction lives

Every API paradigm makes a bet about where the pain in a distributed system belongs — in the number of round trips, in the shape of the payload, in the strictness of the schema, or in the ceremony of the contract. REST? bets that HTTP's uniform interface and its caching semantics are worth more than fetching exactly the fields you need. GraphQL? bets the opposite: that a client's exact data shape matters more than uniform caching, so it collapses many REST calls into one query at the cost of a more complex server. gRPC bets that internal, high-throughput service-to-service calls should pay for a binary wire format and generated stubs up front, in exchange for speed and streaming. SOAP bets that a machine-verifiable, heavily-typed contract (WSDL, XML Schema) is worth the verbosity, because the cost of a mismatched integration in banking or healthcare is higher than the cost of a bulkier envelope.

None of these are strictly "better" — they answer to different anxieties. A public API with thousands of unpredictable consumers wants REST's cacheability and its enormous ecosystem of generic tooling. A mobile app on a slow, metered connection wants GraphQL's ability to ask for exactly the seventeen fields the screen needs instead of six over-fetched REST responses. A fleet of internal microservices doing a hundred thousand calls a second wants gRPC's binary framing and HTTP/2 multiplexing. A legacy enterprise integration with a bank wants SOAP's rigid, generated contract and its built-in standards for transactions and security (WS-Transaction, WS-Security) that REST never fully replaced.

#Side by side

#What the request actually looks like

#Picking one, in practice

• If your consumers are unknown, numerous, and want to build on top of you for years — REST. The ecosystem (caches, proxies, API gateways, monitoring) already understands it.
• If you own both ends and your bottleneck is the client shaping many different views out of the same data (a dashboard, a mobile app, a public API layer feeding a single-page app) — GraphQL, usually as a gateway in front of REST or gRPC services rather than a full replacement.
• If both ends are services you control, latency and throughput matter, and you want compiler-checked contracts across languages — gRPC.
• If you are integrating with an enterprise or government system that already speaks SOAP and demands WS-Security or distributed transactions — SOAP, because that ecosystem was never really about JSON versus XML, it was about the standards built on top of the envelope.

🧠 Check your understanding
0/3 · 0/3 answered
1. A team is building a public API that thousands of unknown third parties will integrate with over the next five years. Which paradigm gives them the most out-of-the-box tooling (proxies, caches, API gateways)?
RESTGraphQLgRPCSOAP
2. Why is a naive GraphQL resolver for a list of users' orders prone to an N+1 query problem?
GraphQL requires XML parsing for every fieldgRPC does not support paginationEach field can be resolved independently, so resolving 'orders' once per user in the list issues one query per user unless batchedGraphQL forces all queries to run over UDP
3. What is the main reason gRPC is a poor fit for a public browser-facing API without an intermediary?
gRPC has no concept of a client libraryProtobuf cannot represent nested objectsBrowsers cannot natively speak the framing gRPC needs, so it typically requires grpc-web and a proxyIt cannot use HTTP/2