HTTP vs RPC in Spring Cloud: A Comparative Overview

Spring Cloud relies on an embedded Tomcat container to expose web services, allowing developers to handle HTTP requests with JSON payloads. HTTP is cross‑platform, flexible for business data exchange, and can serve mobile, H5, and mini‑program clients from a single server.

RPC, built on TCP, requires a three‑way handshake and binary serialization, making it suitable for stable, low‑change data formats but less adaptable for frequent data structure changes. A typical RPC setup involves a client socket (ClientSocket) and a server socket (ServerSocket) with a listen‑request‑confirm flow.

The article explains the basics of a simple HTTP server in Java, then defines RPC as a remote procedure call mechanism that abstracts network details from the programmer.

Key differences:

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

HTTP does not impose such constraints; developers must implement request/response handling themselves.

Advantages:

RPC offers transparency for users.

HTTP provides flexibility, language‑agnostic and cross‑platform communication.

Disadvantages:

RPC needs API encapsulation, limiting language choices.

Selection criteria consider speed (RPC can be faster but HTTP can be compressed), implementation complexity (RPC is more complex), and flexibility (HTTP wins for cross‑platform needs).

Future trends point to microservices favoring HTTP/RESTful services, as RPC’s constraints are less suitable for autonomous, loosely coupled services.