Remote Procedure Calls

A JSON-RPC 2.0 request carries jsonrpc "2.0", a method, optional params (an Array or an Object) and an id. The response echoes that id and carries exactly one of result or error, so the client correlates by id.

The client stub poses as the local procedure: it marshals the arguments into a request and hands it to the transport. The server skeleton unmarshals them, dispatches to the real procedure and marshals the result back.

RPC exposes named procedures the client calls with arguments; REST exposes addressable resources handled through HTTP's fixed methods; GraphQL exposes one typed graph the client queries for exactly the fields it wants. That organising choice drives caching, coupling and tooling.

Maybe sends once and never resends, so the call ran zero or one times. At-least-once resends until a reply arrives, so it may run repeatedly. At-most-once also resends, but the server spots duplicates by request identifier and replays its saved reply.

A call is safe to re-invoke when two runs leave the same intended state as one: reads and absolute writes like 'set address to X'. 'Add 10 points', 'create order' or 'send email' are unsafe unless the server filters repeats.

JSON-RPC 2.0 reserves -32700 (parse error), -32600 (invalid request), -32601 (method not found), -32602 (invalid params) and -32603 (internal error), with -32000 to -32099 for implementation-defined server errors. The id is null when it could not be determined.

Waldo et al. argue local and remote objects differ in latency, memory access, partial failure and concurrency, so an interface designed for local use cannot simply be made remote later; failure and concurrency must be designed in from the start.

Arguments are marshalled into a message, so the server fills a copy decoded on its own side. Its additions never travel back unless the interface returns them as a result or an output parameter; caller and server share no memory.

Ask whether the identical request could ever succeed. Transient errors come from processing conditions — overload, an unreachable upstream — and may clear; permanent ones come from the request itself — bad arguments, unknown method, refused credentials — and recur until it changes.

A JSON-RPC 2.0 batch is an Array of Request objects; the server answers with an Array of Responses, one per non-notification, in any order, matched by id. Invalid JSON or an empty Array gets one error object; an all-notification batch gets nothing.

A JSON-RPC 2.0 notification is a Request object with no id member at all. The server MUST NOT reply to it — not on success, not on error, not inside a batch — so the client never sees errors such as invalid params.

Besides blocking until the reply arrives, a caller can take a future or callback (asynchronous), send one-way or batched calls that get no reply, or stream many messages in one call. Each trades the local-call illusion for concurrency, throughput or incremental data.

The call model defines messages, not delivery. A binding supplies message boundaries on a byte stream, the transport's size limits, how replies pair with calls and, on datagrams, timeouts, retransmission and duplicate detection; finding the server is separate again.

RPC, REST and GraphQL faces return the outcome in the same exchange - a typed result or error, an HTTP status, a selected payload; a command message returns only acceptance, the outcome arriving later. Each couples the caller to different things.

Shared HTTP caches reuse responses to safe GET requests, keyed on the URL, so per-item catalogue URLs are served from browsers, proxies and CDNs. RPC or GraphQL POSTs to one endpoint hide the operation in the body, defeating those caches.

No protocol makes a lossy network execute a call exactly once. 'Exactly-once' is at-least-once resending plus execution that absorbs repeats — an idempotent procedure or server-side duplicate filtering — and it breaks wherever that filter forgets or misses a repeat.

JSON-RPC 2.0 defines only objects and their processing rules. A protocol carrying it must define message framing on a stream, any HTTP mapping (method, status codes, what a notification gets), which side may send requests, and cancellation or timeouts.

Usually not one style. Standardise the decision: a default per consumer - REST for public and partner HTTP, an IDL-based RPC framework internally, GraphQL for client-composed views, messaging where no immediate answer is needed - plus shared conventions and a recorded exception path.

The request names its target - a service or program, often a version, and a procedure - and the dispatcher looks it up. An unknown service, version or procedure, or arguments that will not decode, are reported before any handler runs.

Orphans are server executions whose caller crashed or stopped waiting. They waste resources, hold locks and can apply effects the restarted client does not expect. Systems cancel them on request, abort them by client epoch, or let them expire.

JSON-RPC 1.0 marks a notification with id null and sends no jsonrpc member, so a strict 2.0 server sees a request to answer or reject. 2.0 also adds named params, result-or-error responses, defined error codes, batches and reserved rpc. names.

A google.api.http HttpRule names an HTTP verb and a URL template whose path variables bind request fields, plus a body mapping; a transcoder converts HTTP/JSON to the gRPC call. The JSON face loses streaming, trailer metadata and typed error fidelity.