Understanding RPC vs HTTP: Architecture, Call Types, and Popular Frameworks

Introduction

The author, a senior architect, notes that many developers confuse RPC (Remote Procedure Call) with HTTP calls, assuming both simply involve writing a service and invoking it from a client.

OSI Model Overview

Before comparing RPC and HTTP, the article reviews the OSI seven‑layer model (Application, Presentation, Session, Transport, Network, Data Link, Physical), emphasizing that in practice the Presentation and Session layers are often merged with the Application layer.

Core Differences

RPC is built on the TCP/IP protocol stack, while HTTP services operate at the application layer using the HTTP protocol. Because HTTP runs over TCP, RPC can achieve higher efficiency in many scenarios.

RPC Service Architecture

An RPC system typically consists of four core components:

Client – the caller of the service.

Server – the provider of the service.

Client Stub – packages request parameters and sends them over the network.

Server Stub – receives the request, unpacks it, and invokes the local method.

These components enable decoupling of client and server, reduce JAR size on the client side, and improve portability.

Synchronous vs Asynchronous Calls

Synchronous calls block the client until the result is returned; asynchronous calls return immediately and notify the client later via callbacks, Futures, or Runnables.

Popular RPC Frameworks

gRPC – Google’s open‑source framework based on HTTP/2, supporting multiple languages and built on Netty.

Thrift – Facebook’s cross‑language service framework with an IDL and code generator.

Dubbo – Alibaba’s widely used RPC framework featuring pluggable protocols and serialization.

HTTP Service Overview

HTTP services (often RESTful) are simple, direct, and fast to develop, suitable for small‑scale integrations. They rely on standard HTTP methods and JSON/XML payloads.

When to Choose RPC vs HTTP

For large enterprises with many subsystems and high performance requirements, RPC offers persistent connections, reduced handshake overhead, and built‑in service registries. For lightweight, rapidly evolving APIs, HTTP remains a pragmatic choice.

Conclusion

Choosing between RPC and HTTP should be based on a thorough evaluation of project needs rather than popularity; each approach has distinct trade‑offs.

Code Example

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