RPC 与 REST 的对比表

对比维度	RPC（Remote Procedure Call）	REST（Representational State Transfer）
出现时间	1970s（最早） 广泛使用于1980s~1990s	2000年 由 Roy Fielding 提出
提出者	最早由 Bruce Jay Nelson 提出（1976）	Roy Fielding（HTTP 的核心作者之一）
设计理念	像调用本地函数一样远程调用服务的方法	通过传输资源状态的表述，使用标准的 HTTP 方法
通信方式	自定义协议 / HTTP / TCP / SOAP 等	只使用 HTTP 协议
接口风格	方法导向：调用远程方法（如 getUser()）	资源导向：操作资源（如 GET /users/1）
常见协议	SOAP、gRPC、XML-RPC、JSON-RPC	纯 HTTP（GET、POST、PUT、DELETE）
数据格式	通常是 XML、protobuf、JSON	通常是 JSON、XML、HTML
资源定义	方法名即 API（如 createUser()）	URI 即资源名（如 /users）
耦合程度	较高：客户端需要知道方法签名	较低：基于资源、统一协议
常见使用场景	微服务之间高效通信（如 gRPC） 内部系统集成	Web服务、前后端通信、开放API、移动端接口
扩展性	强，但需遵守接口协议	高，适合互联网和跨平台
调试难度	通常较难（尤其是二进制协议如 gRPC）	调试方便（浏览器、Postman 可直接测试）

 

作者

• RPC：
  • 作者：Bruce Jay Nelson 是 RPC 概念的提出者，他在 Xerox PARC 的研究奠定了 RPC 的理论基础。后来，Sun Microsystems（现为 Oracle）通过 Sun RPC（ONC RPC）推广了这一技术。
  • 贡献：Nelson 的工作专注于让分布式系统中的远程调用像本地调用一样透明，简化开发。
• REST：
  • 作者：Roy Fielding，他在 Apache HTTP Server 项目中是核心贡献者之一，并在 2000 年的博士论文中定义了 REST 架构风格。
  • 贡献：Fielding 的 REST 基于 Web 的架构原则，强调资源导向、无状态性和 HTTP 协议的标准化使用。

对比：RPC 的作者 Nelson 专注于分布式计算的透明性，而 Fielding 的 REST 更关注 Web 的可扩展性和标准化。两者作者背景不同，分别代表了不同时代的技术需求。

---

3. 使用场景

• RPC：
  • 核心特点：
    • RPC 模拟本地函数调用，客户端通过调用远程服务上的“过程”（函数）来完成操作。
    • 强耦合，客户端和服务器需要共享接口定义（如 IDL 文件）。
    • 通常使用专有协议或 TCP/IP，数据格式不固定（可能是二进制或自定义格式）。
  • 典型场景：
    1. 企业内部系统：如银行、金融系统中的分布式计算，调用远程服务执行复杂业务逻辑。
    2. 高性能计算：需要低延迟、强一致性的场景，如分布式数据库或实时系统。
    3. 遗留系统：早期企业应用（如 CORBA、DCOM）中广泛使用 RPC。
    4. 微服务内部通信：在某些微服务架构中，服务间需要快速、同步的函数调用时使用 RPC（如 gRPC）。
    5. 嵌入式系统：在资源受限的设备中，RPC 提供高效的远程调用机制。
  • 优缺点：
    • 优点：调用简单，像本地函数调用；性能较高（尤其 gRPC 使用 HTTP/2 和二进制格式）。
    • 缺点：紧耦合，难以跨平台；协议不统一，扩展性较差；不适合公开 API。
• REST：
  • 核心特点：
    • REST 以资源为中心，使用 URL 标识资源，通过标准 HTTP 方法（GET、POST、PUT、DELETE）操作。
    • 无状态、松耦合，通常使用 JSON 或 XML 作为数据格式。
    • 基于 HTTP 协议，易于与 Web 集成。
  • 典型场景：
    1. Web 和移动应用：前后端分离架构中，前端通过 REST API 获取数据（如社交媒体、电商 App）。
    2. 微服务架构：服务间通过 REST API 实现松耦合通信，适合异构系统。
    3. 公开 API：第三方服务集成，如支付网关（Stripe）、地图服务（Google Maps）、社交登录（OAuth）。
    4. 物联网（IoT）：设备通过 REST API 与云端交互，发送数据或接收指令。
    5. 内容管理系统（CMS）：Headless CMS 通过 REST API 提供内容给不同前端。
    6. 云服务和 DevOps：AWS、Azure 等通过 REST API 提供自动化操作接口。
  • 优缺点：
    • 优点：简单、跨平台、易于扩展；基于 HTTP，天然支持 Web；适合公开 API 和异构系统。
    • 缺点：无状态可能导致请求开销大（如重复传输元数据）；性能可能不如 RPC（尤其在高并发场景）。

对比：

• RPC 适合需要高性能、强耦合、内部系统的场景，如企业内部分布式系统或微服务间低延迟通信。
• REST 更适合 Web 环境、跨平台、公开 API 和松耦合的场景，广泛应用于互联网应用和第三方集成。
• RPC 强调“过程调用”，REST 强调“资源操作”，REST 的通用性和标准化使其在现代 Web 开发中更占主导地位。

 

注:当前文章会不定期进行更新。如果您对本文有更好的建议，有新资料推荐， 可以点击： 欢迎分享优秀网站 。