RPC

RPC, or Remote Procedure Call, is the oldest idea in distributed computing that keeps coming back: let a client invoke a named procedure on a remote machine as if it were calling a local function. Instead of modeling an API around resources and HTTP verbs the way REST does, RPC models it around actions — you call getUser or createOrder and get a result. The pattern shows up across decades of protocols, from XML-RPC and JSON-RPC to gRPC and, most recently, the Model Context Protocol.

• Action-oriented - The unit of design is a procedure or method, not a resource, which maps cleanly onto how developers already think about code.
• Transport and encoding vary - RPC rides over HTTP, HTTP/2, or raw sockets, encoding payloads as XML, JSON, or binary Protocol Buffers depending on the flavor.
• Tight, generated contracts - Frameworks like gRPC generate client and server stubs from an IDL, giving you a strongly-typed contract and a smaller wire footprint than JSON over REST.
• Streaming and low latency - HTTP/2-based RPC supports bidirectional streaming and multiplexing, which is why it dominates internal, high-throughput service-to-service traffic.

In real API operations I see RPC living mostly behind the gateway, powering internal microservice meshes where gRPC’s speed and typed contracts matter more than public browsability. The agentic turn has given RPC a second public life: JSON-RPC is the wire format under MCP, so tool-calling agents are effectively making remote procedure calls again. That makes it worth governing RPC contracts with the same discipline we apply to OpenAPI — clear schemas, versioning, and discoverability — even when the surface is a method name rather than a URL.