RPC 与 REST 的分野
RPC（远程过程调用）把远程调用包装成本地函数调用，以「方法 + 参数」为一级概念，gRPC、Thrift、JSON-RPC、Dubbo 都属于这一类；REST 以「资源 + 表述」为一级概念，用 URL 定位业务对象、用 HTTP 方法表达意图、用状态码表达结果。两者都可以跑在 HTTP 上，差别在抽象模型与治理方式，不在传输层，因此「用了 HTTP 就是 REST」是常见误解。
基本信息
| 代表实现 | RPC：gRPC（HTTP/2 + Protobuf）、Thrift、JSON-RPC、Dubbo；REST：基于 OpenAPI 描述的 HTTP 接口 |
|---|---|
| 接口契约 | RPC 用 IDL 生成强类型桩；REST 用 OpenAPI 描述资源与操作 |
| 典型调用方 | RPC：内网服务间、移动端长连接；REST：第三方接入、浏览器、跨组织集成 |
| 调用形态 | gRPC 支持一元、服务端流、客户端流与双向流；REST 以请求响应为主 |
维度对比
| 维度 | RPC | REST |
|---|---|---|
| 抽象模型 | 方法与消息 | 资源与表述 |
| 契约工具 | IDL 生成强类型桩，编译期检查 | 通用 HTTP 客户端，运行期解析 |
| 演进耦合 | 接口与版本绑定较紧 | 资源可增量扩展，演进较独立 |
| 缓存与网关 | 需自行实现，HTTP 语义利用少 | 直接复用缓存、代理与 CDN |
| 适配场景 | 内网高频、低延迟、需要流式 | 对外开放、弱耦合、缓存友好 |
选择依据
- 调用双方是否同一组织、能否同步升级：能同步升级偏 RPC，需长期兼容老客户端偏 REST
- 是否需要服务端推送或双向流：需要则 HTTP/2 上的 gRPC 更省事
- 是否有第三方与浏览器直连：有则 REST 的通用工具链成本更低
- 是否对带宽与序列化开销敏感：Protobuf 二进制编码通常比 JSON 更紧凑
同一业务的两种写法
同一业务的两种写法
POST /v1/orders/create # RPC 风格：动词进路径
POST /v1/orders # REST 风格：资源定位，方法表意
GET /v1/orders/1001 # 资源标识直接进路径
# gRPC 侧：方法写在 IDL 里，URL 不承载语义
# rpc CreateOrder(CreateOrderReq) returns (Order)同一份对外接口里混用两套抽象（既有按动作命名的路径，又有按资源命名的路径）会让网关的鉴权、缓存与限流规则难以统一，选型应在接口规范层面固定下来。
两者并非路线之争：常见做法是内网服务间用 gRPC 保证性能与流式能力，边界处用 REST 对外开放，靠统一契约与代码生成工具保证两侧一致。