Chapter 3: gRPC vs REST vs GraphQL vs SOAP

You can't understand when to use gRPC without understanding what it's competing against. Let's do a deep, honest comparison.

Paradigm Differences

These four technologies represent fundamentally different philosophies:

REST: The Incumbent

REST models everything as resources accessed via HTTP verbs:

// REST: resource-oriented
GET    /users/123          → Get user 123
POST   /users              → Create a user
PUT    /users/123          → Update user 123
DELETE /users/123          → Delete user 123
GET    /users/123/orders   → Get user's orders

// gRPC: action-oriented
GetUser(GetUserRequest{id: 123})
CreateUser(CreateUserRequest{name: "Alice"})
UpdateUser(UpdateUserRequest{id: 123, name: "Bob"})
DeleteUser(DeleteUserRequest{id: 123})
ListUserOrders(ListUserOrdersRequest{user_id: 123})

When REST Wins

• Public APIs — browsers speak HTTP+JSON natively
• Caching — HTTP caching (CDN, browser cache) works out of the box
• Simplicity — curl a URL, get a response. No tooling needed.
• Discoverability — HATEOAS, human-readable responses
• Ecosystem — every language, every framework, every tool supports REST

When gRPC Wins Over REST

• Performance — Protobuf is 3-10x smaller than JSON, 5-100x faster to serialize
• Streaming — native bidirectional streaming (REST has no real equivalent)
• Strong typing — compile-time type safety, no "oops, the field was a string not an int"
• Contract-first — the .proto IS the contract, not an afterthought
• Multiplexing — HTTP/2 means many RPCs on one connection
• Deadlines — built-in timeout propagation across service chains

Performance: The Numbers

Real benchmarks (approximate, varies by payload):

GraphQL: The Query Language

GraphQL (Facebook, 2015) solves a different problem: letting clients request exactly the data they need.

// GraphQL: client specifies what it wants
query {
  user(id: 123) {
    name
    email
    orders(last: 5) {
      id
      total
    }
  }
}

GraphQL vs gRPC

• GraphQL is for flexible client queries (mobile apps needing different data than web)
• gRPC is for efficient service-to-service communication (backend microservices)
• They solve different problems and can coexist: GraphQL at the edge, gRPC internally

SOAP: The Enterprise Legacy

SOAP is still alive in banking, healthcare, and government. It's XML-based RPC with enterprise features:

• WS-Security (encryption, signatures)
• WS-ReliableMessaging (guaranteed delivery)
• WS-Transaction (distributed transactions)
• WSDL (formal contract)

gRPC replaces SOAP in new systems because it's faster, simpler, and achieves the same goals (strong contracts, code generation) without the XML bloat.

Decision Matrix

The Hybrid Reality

In production systems, you rarely use just one. A typical architecture:

REST/GraphQL at the edge (for browsers), gRPC internally (for performance and type safety).

Common Misconceptions

Telecom Perspective

In 3GPP 5G Service-Based Architecture:

• The SBI (Service-Based Interface) between NFs uses HTTP/2 + JSON (essentially REST-like)
• This was a deliberate 3GPP choice for interoperability between vendors
• But within a NF (e.g., inside AMF's microservices), gRPC is common because you control both sides
• The performance difference matters when you're handling millions of UE registrations