Understanding RPC vs HTTP: Architecture, Advantages, and Choosing the Right Interface

Both HTTP and RPC interfaces are widely used in production; HTTP interfaces use URL‑based parameters over the HTTP protocol, while RPC interfaces rely on Remote Procedure Calls.

RPC ( Remote Procedure Call ) and HTTP ( HyperText Transfer Protocol ) differ in that RPC is a method and HTTP is a protocol. RPC services typically operate over TCP (or optionally HTTP), making them lighter and more efficient than pure HTTP services, which run on top of HTTP that itself uses TCP.

Both are built on a Client/Server architecture.

RPC (Remote Procedure Call) Service

An RPC service consists of four core components: Client, Server, Client Stub, and Server Stub.

Client : the service caller.

Server : the service provider.

Client Stub : stores the server address, packages request parameters into a network message, and sends it to the server.

Server Stub : receives the client message, unpacks the request, processes it, and returns the result.

RPC offers clear efficiency advantages: once the client and server agree on request and response schemas, each side can be developed independently, enabling decoupling and reuse across multiple projects.

RPC calls can be synchronous (client waits for a result) or asynchronous (client proceeds without waiting, using callbacks or one‑way calls).

Popular RPC Frameworks

gRPC : Google’s open‑source project based on HTTP/2, supporting many programming languages and built on Netty.

Thrift : Facebook’s cross‑language service framework with an IDL code generator that abstracts the underlying RPC communication.

Dubbo : Alibaba’s widely adopted RPC framework with pluggable protocols and serialization.

HTTP Service

HTTP services are accessed via URLs; browsers also count as HTTP clients, though they render the server’s response.

Developing an HTTP service typically follows a RESTful style, which is simple, direct, and convenient for low‑traffic or loosely coupled systems.

When many internal subsystems and numerous interfaces exist, RPC frameworks shine because they provide long‑living connections, built‑in load balancing, rich service‑governance features, and transparent versioning.

RESTful

Restful web service follows a Resource‑Oriented Architecture (ROA). Example of pre‑REST URLs:

http://127.0.0.1/user/query GET – query user by ID

http://127.0.0.1/user/save POST – create user

http://127.0.0.1/user/update POST – update user

http://127.0.0.1/user/delete GET/POST – delete user

RESTful style consolidates these into a single resource URL:

http://127.0.0.1/user GET – query

http://127.0.0.1/user POST – create

http://127.0.0.1/user PUT – update

http://127.0.0.1/user DELETE – delete

Differences and Relationships Between RPC and HTTP

RPC behaves like a local method call to a remote service, while HTTP is a request/response protocol (POST, GET, etc.).

Transport Protocol

RPC can run over TCP or HTTP.

HTTP runs exclusively over HTTP.

Transmission Efficiency

RPC can use custom lightweight TCP protocols or HTTP/2, reducing payload size.

HTTP/1.1 carries extra overhead; HTTP/2 can be more efficient but still often uses JSON, which is bulkier than binary formats like Thrift.

Performance Cost

RPC frameworks (e.g., Thrift) can achieve high‑performance binary transmission.

HTTP usually relies on JSON, which incurs larger payloads and higher serialization cost.

Load Balancing

Most RPC frameworks include built‑in load‑balancing strategies.

HTTP requires external solutions such as Nginx or HAProxy.

Service Governance

RPC can automatically notify downstream services of changes, minimizing impact.

HTTP often needs manual configuration updates (e.g., Nginx) before changes take effect.

RPC is typically used for internal service calls where low latency and high throughput are critical, while HTTP is preferred for external, heterogeneous environments, browser interactions, mobile app APIs, and third‑party integrations.

How to Choose?

Speed: RPC is generally faster because it avoids the verbosity of HTTP.

Complexity: RPC implementations are more complex; HTTP is simpler to set up.

Flexibility: HTTP excels in cross‑language, cross‑platform scenarios.

Use RPC when performance is paramount and the tech stack is uniform; use HTTP/REST when flexibility, cross‑platform compatibility, and ease of integration are more important.

Modern micro‑service architectures often favor HTTP/REST for external interfaces while still employing RPC (or proprietary protocols like HSF) for internal high‑performance communication.

References

https://www.cnblogs.com/Dong-Ge/articles/9577019.html

https://www.jianshu.com/p/9ccdea882688

https://www.cnblogs.com/111testing/p/11297037.html