Appearance
gRPC 与 REST：按客户端、契约和故障处理选通信方式
修订于 2026-10-12。本文不提供脱离负载条件的速度倍数。
REST 通常以 HTTP 资源与表示组织接口；gRPC 使用服务与方法定义，常配合 Protocol Buffers 生成客户端和服务端代码。两者都可用于服务间通信，选型不能只依据一次序列化基准测试。
| 关注点 | gRPC | REST/HTTP |
|---|---|---|
| 契约 | 明确的服务与消息定义，支持代码生成 | 可使用 OpenAPI 等方式描述资源接口 |
| 交互 | 单次调用以及服务端、客户端、双向流 | 常规请求响应更直接；流式能力取决于实现 |
| 浏览器和外部伙伴 | 需确认客户端与网关支持 | HTTP 工具链和调试方式较普遍 |
| 错误 | gRPC 状态码与 metadata | HTTP 状态码与响应体约定 |
gRPC 官方文档提醒：客户端达到 deadline，不代表服务端之前的副作用已回滚。写操作重试仍需处理幂等、超时预算和“结果未知”的状态。流式调用还要监控背压、取消和长连接故障。
决策步骤
先列出调用方类型、数据大小、流式需求、版本兼容与安全约束。实现一条代表性链路，在目标网络和部署方式下测端到端延迟、错误恢复与运维成本。允许内部服务与外部 API 使用不同接口风格，避免为了统一而让某一类客户端承担额外复杂度。