SOAP and gRPC — Contract-First Calls
BookNook has to talk to two outsiders. A national library network, built in the 2000s, only speaks SOAP. Inside BookNook, the search service must answer the loans service thousands of times a second. The first is heavy and old, the second fast and modern, yet both share one idea: the contract is written before the code, and the call looks like calling a function on another machine.
The rule
Write the contract first; generate the code; call remote functions.
Both styles are forms of RPC (remote procedure call): instead of acting on resources with HTTP verbs, you call named operations like GetBook or ReserveTitle.
SOAP sends XML messages wrapped in an envelope, almost always as POST. Its contract is a WSDL file, an XML description of every operation and type. Tools read the WSDL and generate client code.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<ReserveTitle><isbn>9780261103344</isbn></ReserveTitle>
</soap:Body>
</soap:Envelope>SOAP brings formal standards for security and reliable messaging, which is why banks and governments adopted it. It is also verbose and awkward from a browser.
gRPC writes its contract in a .proto file using Protocol Buffers, a compact binary format, and runs over HTTP/2:
service Search {
rpc FindBooks (FindRequest) returns (FindReply);
rpc WatchAvailability (BookId) returns (stream Availability);
}
message FindRequest { string text = 1; int32 limit = 2; }- Code for many languages is generated from the
.proto, so client and server cannot disagree on field names or types. - Messages are small and quick to parse.
- HTTP/2 allows streaming: the server, the client, or both can send a stream of messages, as
WatchAvailabilitydoes. - Browsers cannot call gRPC directly; they need a translating proxy such as gRPC-Web.
The shortcut
Match the style to the caller: public or browser callers → REST or GraphQL; internal service-to-service speed → gRPC; a partner who already speaks SOAP → SOAP.
The public website and apps
Many unknown callers, browsers, caching: REST (maybe GraphQL for app screens).
The trap is choosing by fashion. gRPC is not "better REST"; it is a different tool for a different caller.
Drills
Answer fast — trust the rule.
What file describes a SOAP service's operations and types?
Which pair describes gRPC?
BookNook's website JavaScript wants to call the search service's gRPC API directly. What is the catch?
What do SOAP and gRPC have in common?
The server should push availability changes to a client as they happen. Which gRPC feature fits?
Remember
- Write the contract first; generate the code; call remote functions.
- Shortcut: public and browser → REST/GraphQL; internal speed → gRPC; legacy partner → SOAP.
- Trap: picking by fashion instead of by who the caller is.