Understanding RPC vs HTTP: Architecture, Differences, and Popular Frameworks

The author, a senior architect, starts by pointing out the common confusion between RPC (Remote Procedure Call) and HTTP calls, noting that many developers treat them as interchangeable.

To clarify, the article briefly revisits the OSI seven‑layer network model (Application, Presentation, Session, Transport, Network, Data Link, Physical) and emphasizes that RPC primarily operates at the transport layer (TCP), while HTTP is an application‑layer protocol.

It then outlines the essential components of a typical RPC architecture: a Client, a Server, a Client Stub that packages requests, and a Server Stub that unpacks them and invokes local methods. The author explains how these pieces enable remote method invocation and reduce client‑side dependencies.

The discussion moves to call semantics, distinguishing synchronous calls (the client waits for a result) from asynchronous calls (the client proceeds without waiting, using callbacks or futures). Java’s Callable and Runnable interfaces are used as examples of how to implement each style.

Three widely used open‑source RPC frameworks are introduced:

gRPC : Google’s framework built on HTTP/2, supporting multiple languages and leveraging Netty.

Thrift : Facebook’s cross‑language service framework with an IDL and code generation.

Dubbo : Alibaba’s mature RPC solution with pluggable protocols and serialization, often used in large‑scale Java micro‑services.

For contrast, the article describes traditional HTTP/REST services, showing a simple POST example (wrapped in a code block):

POST http://www.httpexample.com/restful/buyer/info/shar

It notes that HTTP is straightforward, language‑agnostic, and suitable for smaller projects or low‑traffic APIs.

Finally, the author compares the two approaches: RPC offers higher efficiency, persistent connections, and rich monitoring for large enterprises, whereas HTTP provides simplicity and rapid iteration for smaller services. The conclusion advises choosing the technology based on project size, performance needs, and ecosystem compatibility.