Why Spring Cloud Chooses HTTP Over RPC for Remote Calls

Spring Cloud enables remote calls using HTTP rather than RPC. The framework relies on an embedded Tomcat container to process HTTP requests, allowing developers to exchange JSON resources, respond flexibly, and support cross‑platform interactions suitable for microservices serving web, mobile, and mini‑program clients.

RPC operates over TCP, requiring a three‑way handshake to establish a reliable connection before data transmission. Because TCP works at the transport layer, RPC depends on binary serialization and deserialization, making it less adaptable for applications that need frequent data format changes; it is typically used for stable, low‑change data exchanges.

Establishing a socket connection involves a client socket and a server socket, with the connection process consisting of server listening, client request, and connection confirmation.

Simple HTTP Request Handling

In a web application, a browser requests a URL, and the server returns the generated HTML page via the HTTP protocol. The following example demonstrates how to implement a basic HTTP server in Java.

RPC

Remote Procedure Call (RPC) is an inter‑process communication method that allows a program to invoke a procedure on a remote machine as if it were local, abstracting away the network details.

For example, if two servers A and B host separate applications, A can call methods provided by B through RPC, despite being in different JVMs and machines.

RPC consists of two core modules: communication and serialization.

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

Restful (HTTP)

RESTful describes a set of architectural constraints and principles. When an architecture complies with these constraints, it is considered RESTful. Although REST is heavily influenced by web technologies, it is not strictly bound to HTTP; however, HTTP is the most common implementation.

Differences Between RPC and HTTP

Both RPC and HTTP involve request‑response interactions, but they differ in several ways:

RPC aims to make remote calls appear as local calls, requiring API‑level encapsulation.

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

Advantages:

RPC offers transparency and convenience for users.

HTTP provides greater flexibility, being language‑agnostic and cross‑platform.

Disadvantages:

RPC’s need for API encapsulation can limit language choices.

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; HTTP is simpler.

Flexibility: HTTP is more flexible, allowing cross‑platform and cross‑language communication without detailed implementation constraints.

Future Development Direction

Microservice architectures emphasize independence, autonomy, and flexibility. Because RPC imposes more constraints, most microservice frameworks adopt HTTP‑based RESTful services.