Understanding the Differences Between RPC and HTTP Services
This article explains the fundamental differences between RPC and HTTP services, covering OSI model layers, RPC architecture components, synchronous vs asynchronous calls, popular RPC frameworks such as gRPC, Thrift, and Dubbo, and when to choose each approach for enterprise applications.
The author introduces the topic by noting a common confusion between Remote Procedure Call (RPC) and HTTP calls, emphasizing that RPC is based on TCP/IP while HTTP services operate at the application layer.
To clarify the distinction, the article reviews the OSI seven‑layer model (application, presentation, session, transport, network, data link, physical), highlighting that the focus should be on the application and transport layers because HTTP is an application‑layer protocol and TCP resides in the transport layer.
It then presents the RPC service model, outlining its four core components: Client, Server, Client Stub, and Server Stub. The RPC architecture is illustrated with a diagram and described as suitable for large enterprises where efficiency and decoupling are critical.
The discussion moves to call styles, defining synchronous calls (client waits for a response) and asynchronous calls (client proceeds without waiting, using callbacks, Callable/Future or Runnable in Java). Examples of Java interfaces for these patterns are provided.
Next, three popular open‑source RPC frameworks are introduced:
gRPC – Google’s framework built on HTTP/2, supporting multiple languages and using Netty under the hood.
Thrift – Facebook’s cross‑language service framework with an IDL and code generation.
Dubbo – Alibaba’s widely adopted Java RPC framework with pluggable protocols and serialization.
The article then contrasts RPC with traditional HTTP (RESTful) services, noting that HTTP is simple, direct, and fast to develop, suitable for small projects, whereas RPC offers persistent connections, reduced handshake overhead, and built‑in service registries beneficial for large‑scale systems.
A brief HTTP example is shown:
POST http://www.httpexample.com/restful/buyer/info/shar
Finally, the author summarizes that RPC and HTTP serve different scenarios: RPC excels in high‑performance, enterprise‑level environments, while HTTP is better for rapid development and smaller applications. The choice should be based on a thorough evaluation of project requirements rather than trends.
Java Architect Essentials
Committed to sharing quality articles and tutorials to help Java programmers progress from junior to mid-level to senior architect. We curate high-quality learning resources, interview questions, videos, and projects from across the internet to help you systematically improve your Java architecture skills. Follow and reply '1024' to get Java programming resources. Learn together, grow together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.