Spring Cloud Remote Calls: Why HTTP Is Preferred Over RPC

A Simple HTTP Request Handling

In web applications, a browser requests a URL and the server returns the generated HTML page via the HTTP protocol; the following demonstrates how to implement a simple HTTP server in Java.

RPC

RPC (Remote Procedure Call) is an inter‑process communication method that allows a program to invoke a procedure on another address space—typically another machine on a shared network—without the programmer having to code the remote call details.

For example, if two servers A and B each host an application, and the application on A needs to call a method provided by B, the call must travel over the network because the two applications do not share the same JVM memory space; this network‑based invocation is called RPC.

RPC consists of two core modules: communication and serialization.

Note: Regardless of data type, the payload must be serialized into a binary stream for network transmission; the sender serializes objects to binary, and the receiver deserializes the binary stream back into objects.

Restful (HTTP)

Restful refers to a set of architectural constraints and principles; an architecture that satisfies these constraints is called Restful. The idea behind Restful is to leverage existing Web features and standards to build services.

Although Restful is heavily influenced by Web technologies, it is theoretically not bound to HTTP; however, HTTP is currently the primary protocol used to implement Restful services.

Differences Between RPC and HTTP

Both involve request and response cycles.

RPC requires the remote call to appear as a local service call, meaning the API layer must encapsulate the remote invocation.

HTTP does not impose such requirements; developers must implement request and response details themselves.

Advantages

RPC is more transparent to users, making it convenient.

HTTP is more flexible, not tied to a specific API or language, and supports cross‑language, cross‑platform communication.

Disadvantages

RPC requires API‑level encapsulation, which can limit the choice of programming languages.

Selection Considerations

Speed: RPC is generally faster because it uses raw TCP, while HTTP messages are larger but can be compressed with gzip.

Complexity: RPC implementations are more complex, whereas HTTP is relatively simple.

Flexibility: HTTP offers greater flexibility, allowing cross‑platform and cross‑language interactions without concerning low‑level details.

Future Development Direction

Microservices emphasize independence, autonomy, and flexibility; due to RPC’s limitations, most microservice frameworks adopt HTTP‑based Restful services.