GraphQL, gRPC and SOAP
REST with JSON is a sensible default, but it is not the only style. The bookshop's mobile app wants exactly three fields per screen, its internal services call each other thousands of times a second, and the old warehouse system speaks only XML. Each of those problems has a style built for it.
The rule
Let the caller decide: flexible clients, fast services, or old contracts.
GraphQL gives clients one endpoint and a query language. The server publishes a schema of types and fields; the client asks for exactly the fields it wants, even across related data, in one request:
query {
book(id: 42) {
title
author { name }
reviews(first: 3) { rating }
}
}The response mirrors the query's shape. That avoids two REST pains: fetching too much (whole objects when you need two fields) and making many round trips (book, then author, then reviews). The costs: HTTP caching is harder because most queries are POSTs to one URL, and the server must guard against very expensive queries.
gRPC is for service-to-service calls. You define the contract in a .proto file; tools generate typed client and server code in many languages. Messages travel as compact binary Protocol Buffers over HTTP/2, and gRPC also supports streaming.
service Pricing {
rpc GetPrice (PriceRequest) returns (PriceReply);
}
message PriceRequest { int64 book_id = 1; }
message PriceReply { int64 price = 1; }It is fast and strictly typed, but browsers cannot call it directly without a proxy, and binary messages are harder to read by eye.
SOAP is an older standard that wraps every call in an XML envelope, described by a WSDL contract. It is verbose, but it is still common in banking, government and enterprise systems. You rarely choose SOAP for something new; you meet it when integrating with a system that already uses it.
The shortcut
Ask "Who is calling?"
- Many different screens or apps, each wanting different slices of data → GraphQL.
- Your own services talking to each other, fast and typed → gRPC.
- An existing system that demands it → SOAP, kept behind one small adapter.
- Anyone else, especially public or simple APIs → REST with JSON.
The mobile app
The home screen needs titles and covers; the detail screen needs reviews and author bios. One GraphQL query per screen, exactly the fields each needs.
Drills
Answer fast — trust the rule.
What is GraphQL's main advantage for a mobile app with many different screens?
Which style uses .proto contracts and binary messages over HTTP/2?
Which describes SOAP?
A browser page needs to call your internal pricing service directly. Why is plain gRPC awkward here?
Remember
- Let the caller decide: flexible clients, fast services, or old contracts.
- GraphQL = client picks fields; gRPC = typed binary calls between services; SOAP = XML envelopes for legacy systems.
- When no special need applies, plain REST with JSON is the default.