什么场景只能用HTTP，不能用RPC？

2024 年 03 月 13 日

61 次浏览

1876字数

HTTP（Hypertext Transfer Protocol）和RPC（Remote Procedure Call）都是在网络上通信的协议，但两者设计理念和实现方式不同。HTTP更多地面向的是文档传输，而RPC专注于过程或函数的远程执行。在某些场景下，HTTP可能是更合适的选择，而不能或不应该使用RPC。

公共API服务

对于公共API服务，经常推荐使用RESTful API，它是基于HTTP标准和方法（如GET、POST、PUT、DELETE）的。由于HTTP是一种广泛支持和标准化的互联网协议，所以对于公共API来说，使用HTTP能够让更多的客户端轻松消费服务。

浏览器兼容性

当需要与浏览器交互，如服务Web页面或实现AJAX调用时，HTTP是唯一选择。浏览器原生支持HTTP协议，而不支持直接运行RPC调用（除非封装在HTTP中）。因此，在网页前端编程中，HTTP请求是实现客户端与服务器端通信的标准方案。

无状态交互

HTTP是无状态协议，适用于不需要保存客户端状态信息的交互。每个HTTP请求独立处理，服务器不需要保留任何会话状态。对于简单的、无状态的请求，HTTP通常是一个更简单和直观的选择。

易用性和可访问性

由于HTTP协议的普及，大多数编程语言都有成熟的库和工具来处理HTTP请求，使得开发人员能快速和容易地创建HTTP客户端和服务器。此外，对于开发者而言，通过浏览器访问和调试HTTP API也比RPC更为方便。

缓存机制

HTTP自带有效的缓存机制，如HTTP头中的Cache-Control和Etag，可以显著减少不必要的数据传输，提高应用性能。对于那些响应内容不经常改变的服务，HTTP的缓存特性是RPC不具备的优势。

安全性和兼容性

HTTPS（HTTP over TLS/SSL）为HTTP通信提供了端到端加密，这在RPC协议中可能并不总是可用或需要额外配置。同时，由于HTTP(S)的广泛使用，大部分网络设施（如防火墙、代理服务器、负载均衡器等）都默认支持HTTP协议，而采用RPC可能会面临更多配置和兼容性问题。

资源导向交互

特别是当API接口设计为资源导向（RESTful），与资源（如用户、订单、产品等）相关的操作可以映射为HTTP原生的方法。在这种情况下，HTTP作为传输协议是合适的，因为它既简单也直观。

尽管存在上述场景更适合HTTP的情形，这并不意味着RPC在这些情景下绝对不能使用；而是说，在这些特定情况下，HTTP具有比RPC明显的优势，因此开发者更倾向选用HTTP。正如在某些其他场景（如需要高性能、紧密耦合的系统内部通信等）RPC可能是更合适的选择一样。在选择合适的通信协议时，需要根据具体场景、需求及现有基础设施综合考量。