gRPC 与 REST 的差异与选择

结论先行

gRPC 基于 HTTP/2 和 Protobuf，支持流式、强类型和代码生成，适合内部服务间高性能通信；REST 基于 HTTP/JSON，简单、通用、浏览器友好，适合公开 API 和简单集成。内部高并发/流式选 gRPC，公开/浏览器/简单场景选 REST。

核心差异

维度	gRPC	REST
协议	HTTP/2	HTTP/1.1/2
数据格式	Protobuf（二进制）	JSON/XML 等
接口定义	`.proto` + 代码生成	OpenAPI/文档
流式	双向流、服务端流	通常请求-响应
浏览器支持	需 gRPC-Web/代理	原生
性能	高，序列化紧凑	较好，文本较大
调试	需要工具/proto	curl/浏览器直观
缓存	需自行设计	HTTP 缓存成熟

怎么选

内部微服务、低延迟、强类型契约：gRPC。
公开 API、浏览器/移动端、简单集成：REST。
需要双向流、实时推送：gRPC。
需要 HTTP 缓存、CDN、curl 调试：REST。

注意

grpcurl -plaintext localhost:50051 list
grpcurl -d '{"id":1}' localhost:50051 app.UserService/Get
curl -s http://localhost:8080/api/users/1

gRPC 的负载均衡需要 L7 支持；普通 L4 LB 可能把流固定到单实例。
Protobuf 字段编号一旦发布不要复用；兼容性靠字段规则。
gRPC-Web 需要代理/网关转换；不是所有浏览器/网关都支持。
REST 的错误码、分页和幂等设计要统一；不要只靠 200/500。
两者都可以做认证/追踪，但 header 和超时语义不同。
混合架构可以用 gRPC 内部、REST 对外，避免一刀切。

相关命令

grpcurl — gRPC 调试
curl — REST 调试
protoc — Protobuf 编译