Comparison of RPC and HTTP Interfaces: Architecture, Efficiency, and Use Cases

HTTP interfaces and RPC interfaces are both widely used in production; HTTP uses URL‑based parameters over the HTTP protocol, while RPC relies on remote procedure calls.

RPC (Remote Procedure Call) is a method, whereas HTTP (HyperText Transfer Protocol) is a protocol. RPC services typically run on top of TCP (or optionally HTTP), while HTTP services run on HTTP, which itself uses TCP. Because HTTP adds protocol overhead, RPC is generally lighter and more efficient.

Both types are built on a client/server architecture.

RPC (Remote Procedure Call) Service

The basic RPC architecture 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’s message, unpacks the parameters, processes the request, 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 projects.

RPC calls can be synchronous (client waits for a response) or asynchronous (client proceeds without waiting, receiving results via callbacks or notifications).

Popular RPC Frameworks

gRPC : an open‑source project from Google built on HTTP/2, supporting many programming languages and using Netty under the hood.

Thrift : an open‑source framework from Facebook that provides cross‑language service development with an IDL code generator.

Dubbo : an open‑source RPC framework from Alibaba, widely used in internet companies, featuring pluggable protocols and serialization.

HTTP Service

Services invoked via HTTP URLs (including browser requests) are considered HTTP services; they differ mainly in that browsers render the server’s response.

Developing HTTP services typically follows a RESTful style, which is suitable when the number of interfaces is small and inter‑system communication is limited.

Advantages of HTTP include simplicity, directness, and ease of development by leveraging the existing HTTP protocol and defining clear request/response contracts.

In environments with many subsystems and interfaces, RPC frameworks shine because they use persistent connections, provide built‑in registration centers, and support sophisticated service governance such as dynamic scaling and seamless deployment.

RESTful

Restful web service follows a Resource‑Oriented Architecture (ROA). Before RESTful conventions, HTTP APIs often used URLs like http://127.0.0.1/user/query (GET) or http://127.0.0.1/user/save (POST). With RESTful design, the same resources are accessed via uniform URLs such as http://127.0.0.1/user with different HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations.

Differences and Connections Between RPC and HTTP Interfaces

RPC allows remote services to be called as if they were local methods, while HTTP provides standard GET/POST/etc. endpoints.

Transport Protocol

RPC: can run over TCP or HTTP.

HTTP: runs over HTTP.

Transfer Efficiency

RPC: custom TCP or HTTP/2 reduces message size and improves efficiency.

HTTP/1.1: includes extra headers; HTTP/2 can be used as an efficient RPC alternative.

Performance Consumption

RPC: can use binary protocols like Thrift for high performance.

HTTP: often uses JSON, which is larger and slower to serialize.

Load Balancing

RPC: typically includes built‑in load‑balancing strategies.

HTTP: requires external solutions such as Nginx or HAProxy.

Service Governance

RPC: supports automatic notifications for service changes, minimizing impact on upstream callers.

HTTP: changes require manual updates to routing configurations.

RPC is mainly used for internal service calls, offering low performance overhead, high transmission efficiency, and convenient service governance, whereas HTTP is suited for external, heterogeneous environments, browser calls, app APIs, and third‑party integrations.

How to choose between RPC and HTTP?

Speed: RPC is generally faster because HTTP adds more overhead, though compression (e.g., gzip) can mitigate this.

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

Flexibility: HTTP is more flexible, language‑agnostic, and cross‑platform.

Typical scenarios:

If high efficiency and a uniform tech stack are required, RPC is a good choice.

If flexibility, cross‑language, and cross‑platform compatibility are needed, HTTP is preferable.

Modern microservice architectures often favor HTTP/RESTful services for their independence and autonomy, while internal high‑performance needs may still rely on RPC protocols.

References

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

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

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

For readers interested in further advancing their architecture skills, the author invites you to share this article, join the architecture community group, and explore additional resources such as code‑heavy project templates and tutorials.