RPC, JSON-RPC and gRPC

Objectives

By the end of the lesson, you can explain the operation-centred model of RPC, distinguish JSON-RPC from gRPC, and characterise them along the seven aspects.

Why is it needed?

Not every cooperation fits a resource model. If the caller wants to execute an operation ("reserve", "calculate a price"), the operation is the natural centre of the interface. RPC carries this model over the network.

What is RPC?

With RPC (remote procedure call), the operation that can be invoked remotely stands at the centre of the interface: the caller states the operation and the parameters, and the protocol conveys the parameters, the result and the error. The network boundary calls for a suitable operation size: RPC is no licence to publish fine-grained internal methods.

According to the JSON-RPC 2.0 specification, the members of a request are jsonrpc (with the value "2.0"), method (the name of the procedure), params (positional or named parameters, optional) and id (set by the client, for pairing the response). The server returns the same id in the response. A request without id is a notification, to which the server must not reply. The request identifier serves to pair the response; it is not automatically a business idempotency key.

{ "jsonrpc": "2.0", "method": "ReserveSeats",
  "params": { "eventId": "e-12", "seatIds": ["a-1", "a-2"] }, "id": "call-17" }

gRPC

gRPC (a common RPC framework) by default describes the service and the messages in the Protocol Buffers language (in the role of an IDL, that is an interface definition language), and code can be generated from it. The gRPC documentation distinguishes four kinds of calls: unary, server streaming, client streaming and bidirectional streaming.

syntax = "proto3";
service Stock { rpc Reserve(ReserveRequest) returns (ReserveReply); }
message ReserveRequest { string request_id = 1; int32 quantity = 2; }
message ReserveReply { string reservation_id = 1; }

According to the protobuf guide, the field number is the unique identifier of the field in the wire format: it cannot be changed once in use, and the number of a deleted field must not be reused, so the deleted number must be reserved with a reserved marker. A missing field gives a type-dependent default value when read, and with implicit-presence fields an explicit default cannot be distinguished from an unset one. Business validation is needed even with generated types.

Time limit: gRPC uses the concept of a deadline; there is no default, and on expiry a DEADLINE_EXCEEDED error occurs (6.5). Cancellation stops further work, but according to the documentation it does not roll back the changes made before cancellation.

From a browser it cannot be called directly in the usual way: a solution called gRPC-Web lets the browser reach the gRPC service through a proxy.

Characteristics

Aspect	RPC / gRPC
Direction	Request–response; with streaming one- or two-way
Initiator	The client (also with streaming, starting the call)
Connection persistence	Per request, or several kinds of calls on a persistent channel
Latency	One request–response path, often a more compact format
Load	Per call; a stream reduces repeated connection setup
Fault tolerance	Deadline, cancellation; repetition requires idempotency
When it fits	Internal service calls, typed contract, generation, streaming
When it does not	Direct browser calls, many unknown external consumers, cacheable resource reads

Common misconceptions

Statement	Clarification
"gRPC and RPC are the same."	gRPC is one concrete RPC framework.
"RPC means the call is local."	It is a network call: timeout, partial failure.
"The request identifier protects against repetition."	Only if the server treats it as an idempotency key.
"A generated type saves validation."	Business rules must still be checked.

In short

• RPC is operation-centred: the caller invokes a procedure, not requests a resource.
• JSON-RPC is a simple text-based protocol; gRPC is a typed framework with code generation and streaming.
• The field number is part of the contract; a deleted number must be reserved.
• A deadline and cancellation do not undo an already executed change.

Review questions

1. What distinguishes a correlation identifier from an idempotency key?
2. When is a stream justified instead of a unary call?
3. What must be checked when a protobuf schema is modified?

Learning resources

• JSON-RPC 2.0 specification
• gRPC core concepts — kinds of calls, deadline, cancellation.
• gRPC deadlines
• Protocol Buffers: proto3 — field numbers, reserved, default values.