RESTful、GraphQL 和 gRPC 接口风格怎么选

选接口风格没有银弹：对外公开、以资源为中心的接口选 REST；前端多端聚合、字段要按需裁剪的场景选 GraphQL；服务之间高频调用、需要强类型契约和流式传输的内部链路选 gRPC。三者并不互斥，同一套系统按边界混用（对外 REST、BFF 层 GraphQL、内部 gRPC）是当前最主流的落地方式。

REST、GraphQL 和 gRPC 的本质区别是什么？

结论：三者的差异不在语法，而在数据模型、传输协议、契约强制程度这三件事上。

• REST（Representational State Transfer，表述性状态转移）由 Roy Fielding 在 2000 年博士论文中提出，是资源导向：URI 表示资源，HTTP 动词表示操作，状态码表示结果。
• GraphQL 由 Facebook 在 2012 年内部使用、2015 年开源，是查询语言导向：客户端用一条查询描述自己想要的数据形状，服务端按 Schema 返回。
• gRPC 由 Google 在 2015 年开源、2016 年 8 月发布 1.0，是 RPC 导向：像调用本地方法一样调用远端方法，默认走 HTTP/2 + Protocol Buffers（二进制序列化格式）。

什么场景该选 REST？

结论：接口面向第三方开发者、资源边界清晰、需要吃满 HTTP 缓存时，REST 是成本和收益最平衡的选择。

具体做法：用名词做 URI（/orders/123），操作交给动词（GET 查、POST 建、PUT 全量改、PATCH 局部改、DELETE 删）；结果用状态码表达——201 创建成功、400 参数错、401 未认证、403 无权限、404 不存在、409 冲突、422 校验失败。要缓存就在响应里加 Cache-Control 和 ETag，CDN 和浏览器能直接复用。

注意点：不要在 URL 里写动词（/getOrder 是反模式），版本号放进路径或 Header（/v1/）。

什么场景该选 GraphQL？

结论：当一个前端页面要调 5 个以上 REST 接口才能拼出数据，或者字段随版本频繁增删时，GraphQL 的收益最大。

落地必须做三件事：一是限制查询深度（例如最大 10 层）和复杂度计分，防止一条恶意嵌套查询打垮数据库；二是用 DataLoader 做批量加载，解决 N+1 查询问题；三是给热点字段加持久化查询白名单。

它的坑也很明确：HTTP 状态码统一返回 200，真正的错误在响应体的 errors 数组里，监控和告警要按这个改；HTTP 层的缓存基本失效，得靠客户端缓存（如 Apollo 的规范化缓存）或 CDN 对持久化查询做缓存。

什么场景该选 gRPC？

结论：内部微服务之间、延迟敏感、需要服务端流或双向流的链路，选 gRPC。

它支持 4 种调用模式：一元调用、服务端流、客户端流、双向流。字段用 proto3 定义并编号，编号一旦上线就不能改，这是它比 JSON 更严格的契约约束。调试用 grpcurl，代码用 protoc 生成，主流语言都有官方支持。

注意点：浏览器不能直接调 gRPC，需要 grpc-web 或 Envoy 的 HTTP/JSON 转码；抓包看到的是二进制，排查问题比 JSON 费劲，建议在网关层保留访问日志和 trace ID。

三种风格可以混用吗？

结论：可以，而且推荐按边界混用。参考路径是：后端服务之间用 gRPC 保证性能和契约；网关对外暴露 REST 给第三方；前端 BFF 层再加一个 GraphQL 网关聚合多个 REST/gRPC 服务，按页面裁剪字段。这样每一层都用了它最擅长的部分，而不是让一种风格硬扛所有场景。

一句话决策

结论：面向公众、要缓存、要简单——REST；面向自家多端、要按需取字段——GraphQL；面向服务内部、要性能、要流式——gRPC。先看调用方是谁，再看数据形状是否多变，最后看是否需要流式，三步就能定下来。