REST vs SOAP vs GraphQL vs gRPC: How I Actually Choose

API style is an architectural bet on debuggability, caching, and who owns the contract. Here is the framework I use when the choice actually matters.

The question that matters

Teams rarely fail because they picked REST over gRPC. They fail because they picked complexity they did not need — or because they forced REST onto a partner that already publishes a WSDL.

The useful question is not "which is best?" It is: given our clients, our team, and our failure modes, which style minimizes regret in production?

I have shipped REST APIs on Flask, AWS Lambda, and FastAPI for years. This is the comparison I use in design reviews and interviews — focused on trade-offs, not definitions.

REST — the default for a reason

REST models resources (nouns) and uses HTTP methods (verbs):

GET    /orders/42      read           safe, idempotent
POST   /orders         create         not idempotent
PUT    /orders/42      replace        idempotent
DELETE /orders/42      remove         idempotent

Status codes are part of the contract: 201 after create, 404 when the id does not exist, 401 vs 403 for auth vs authorization. Any engineer with curl and logs can debug a REST API at 2 AM.

Choose REST when: public or mobile clients, cacheable reads, broad language support, and operational simplicity matter more than bespoke payload shapes.

Reconsider when: clients consistently over-fetch and product metrics prove it — not because GraphQL is trendy.

SOAP — when the contract arrived before you did

SOAP is not "XML REST." It is a envelope + WSDL contract, usually POST-heavy, common in finance, insurance, and legacy enterprise integrations.

Choose SOAP when: the partner mandates it, you need a formal published contract, or you integrate with systems that predate JSON-first design.

Do not choose SOAP when: you control both sides of a greenfield mobile API. JSON + HTTP will ship and debug faster.

The honest line in a design review: "SOAP is heavier. It is still correct when the other organisation's contract is the product."

GraphQL — client-shaped data at a cost

GraphQL solves over-fetching and under-fetching — one endpoint, client-selected fields. Mobile teams feel this first when REST endpoints return 40 fields for a screen that needs 3.

The costs are real:

HTTP caching on GET does not apply the same way
Expensive queries can become denial-of-service if not rate-limited and cost-analysed
One URL doing many jobs complicates auth and observability

Choose GraphQL when: multiple clients need different slices of the same graph and REST is measurably hurting performance or iteration speed.

Skip it when: a small team maintains two endpoints and a BFF would solve 80% of the problem.

gRPC — internal speed and typed contracts

gRPC uses HTTP/2 + Protobuf. Generated clients, smaller payloads, streaming. Excellent for service-to-service inside a VPC.

Browsers and most external partners expect JSON. gRPC belongs inside the mesh, often behind a REST or GraphQL gateway for public traffic.

Choose gRPC when: low latency, typed contracts, and streaming between services you own.

Do not choose gRPC when: the client is a browser, a third-party integrator, or anyone who needs curl and a JSON body.

Decision lens I use in reviews

Public product API
Choice: REST — debuggability, caching, universal clients.

Partner with WSDL
Choice: SOAP — contract is fixed externally.

Many clients, proven over-fetching
Choice: GraphQL — payload shape per client.

Internal service mesh
Choice: gRPC — performance + typed stubs.

Live updates after load
Choice: WebSockets + REST — wrong tool if you only pick one.

When uncertain, start REST. Add GraphQL as a BFF or gRPC internally later. Starting with maximum complexity is how projects stall before launch.

The interview answer that shows experience

I default to REST because HTTP semantics are operational assets — safe GETs, idempotent PUTs, POST that must not be blindly retried. I use SOAP when the partner requires a WSDL. I consider GraphQL when over-fetching is a measured product problem. I use gRPC internally, not for browsers. The decision follows constraints, not acronyms.

That answer signals you have been paged — not just passed a trivia round.