Why Use RPC When HTTP Exists? Understanding the Differences Between HTTP and RPC

Remote Procedure Call (RPC) and HTTP are both used for remote communication, but they differ fundamentally: RPC typically operates directly over TCP/IP, while HTTP is an application‑layer protocol built on top of TCP. Because RPC bypasses the overhead of HTTP, it can be more efficient for internal service calls.

HTTP Essence

HTTP is a protocol that defines a standardized request/response format: a request line, headers, and an optional body, followed by a response line, headers, and a body. It enables browsers and servers to exchange data such as text, images, video, and audio using a common format.

The protocol acts as a communication contract between client and server, reducing interaction costs by ensuring all parties understand the same message structure.

Relationship Between HTTP and RPC

HTTP is a specific communication protocol, whereas RPC is a concept of remote invocation that can use HTTP or any custom protocol. In microservice architectures, services are split into independent deployments, requiring network calls; RPC frameworks abstract these calls to feel like local method invocations.

public User getUserById(Long id) {
    return userDao.getUserById(id); // local call
}

When the service is remote, the call becomes:

public User getUserById(Long id) {
    return userConsumer.getUserById(id); // remote call via RPC
}

OSI Model Overview

The OSI seven‑layer model helps explain why RPC can be more efficient: HTTP resides in the application layer, while RPC often works directly over the transport layer (TCP), avoiding extra processing in the presentation and session layers.

RPC Service Architecture

An RPC system consists of four core components: Client, Server, Client Stub, and Server Stub. The client stub packages method parameters into a network message, the server stub unpacks the message and invokes the local method, and the result is returned similarly.

Synchronous vs Asynchronous Calls

Synchronous RPC blocks the client until a response is received, while asynchronous RPC allows the client to continue processing and receive the result via callbacks or notifications.

Popular RPC Frameworks

Common open‑source RPC frameworks include:

gRPC : Google’s framework built on HTTP/2, supporting many languages.

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

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

HTTP Services

Typical HTTP services follow the RESTful style, exposing endpoints that accept requests (e.g., POST http://www.httpexample.com/restful/buyer/info/shar) and return JSON or XML. This approach is simple and fast for small‑scale integrations.

For large enterprises with many internal services, RPC offers advantages such as persistent connections, built‑in service discovery, monitoring, load balancing, and richer traffic‑control features that plain HTTP lacks.

Conclusion

Choosing between RPC and HTTP depends on project requirements: RPC suits large, performance‑critical internal systems, while HTTP is ideal for lightweight, public‑facing APIs. Evaluate factors like efficiency, development speed, and ecosystem support before deciding.