REST、GraphQL 和 gRPC 有什么区别？接口设计应该怎么选？

知识点详解：接口选型从调用约束开始，而不是从名词排名开始

先区分契约长什么样

假设页面展示用户资料和最近三条动态。常见资源式 HTTP API 可能提供用户和动态资源；GraphQL 可以让页面请求对应字段组合；gRPC 则可能定义获取资料或聚合信息的具体方法。

REST 不能简单等同于「HTTP + JSON」。它还有无状态、统一接口等架构约束；实际项目常说的 REST API，也未必满足完整 REST 约束。

GraphQL 不限定只能走某一种后端或数据库，gRPC 也不是一个自动替你建业务模型的框架。我们仍然要决定字段含义、错误、权限和兼容规则。

一次网络请求，不等于一次服务端工作

GraphQL 能让调用方选择字段，但服务器需要执行对应解析与数据读取。一个列表里的每个条目再单独查一次数据库，就可能形成 N+1；深层或大范围查询还会放大工作量。

可以安排批量加载、分页、深度或复杂度限制，以及按客户端控制预算。仅限制 HTTP 请求次数，不一定限制住实际成本。

资源式接口或 gRPC 也可能把复杂工作藏在一个入口里。因此，无论选哪一种，都要测数据库查询数、下游调用量和响应体大小，不能把「一个请求」当作性能单位。

缓存与演进，要看整条工具链

资源式 HTTP 接口容易直接利用标准方法、状态码和缓存设施，但个性化数据仍需正确处理缓存范围。GraphQL 的查询形态更多，缓存可放在客户端或服务端，公共 HTTP 缓存则需要结合传输与请求表示来设计。

gRPC 的 Schema 和生成代码能明确契约，但字段演进仍要遵守兼容规则，不能随意复用字段编号。浏览器通常不直接使用原生 gRPC 的完整能力，需考虑 gRPC-Web 与代理；支持的流式形式也要核对实际实现。

所以接入成本是接口能力的一部分，不是选型结束后才发现的小问题。

怎么作一个有依据的选择

假设团队给外部开发者开放一个查询接口，需要方便文档、调试和网关治理，可以先评估标准 HTTP 资源接口。若同一套数据服务多个字段需求差异很大的页面，且团队能治理查询成本，可以评估 GraphQL。

内部服务之间需要强类型契约、代码生成与持续流传输，可以评估 gRPC。不同链路也可以使用不同方式，边缘接口与内部 RPC 不必强行统一。

验证时用相同数据规模与功能，比较端到端延迟、服务端工作、客户端接入和错误排查。不要拿某个空接口压测，得出整套业务的固定性能排名。

本题机制参考：Fielding REST Dissertation、GraphQL Learn、GraphQL Security、gRPC Core Concepts、gRPC-Web Basics。

面试官继续追问

GraphQL 能解决所有过度获取吗？

它允许选择字段，但服务端是否仍读取多余数据，要看实现。字段选择不自动优化数据库查询。

gRPC 一定比 HTTP JSON 快吗？

不能无条件保证。序列化、连接、负载和业务时间不同，结果也不同。应在真实链路比较。

GraphQL 只有一个入口，权限只检查一次行吗？

不行。身份检查之后，还要按字段、资源和操作落实授权。一个查询可以涉及不同权限的数据。

面试速记卡

• REST 是架构约束，不只是 JSON 格式。
• GraphQL 用 Schema 和字段选择表达数据需求。
• gRPC 用服务方法契约与生成代码组织 RPC。
• 一次请求可能包含大量服务端工作。
• 按调用方、契约、成本和工具链选，不作绝对性能排名。