文章详情

每次技术选型会上，总有人提议用GraphQL替换REST。理由通常是前端可以按需取数据，不用再跟后端拉扯字段。但真换了之后，很多团队发现踩的坑比想象的多。到底该选哪个？得看具体场景。

查询效率：GraphQL并不总是更优

GraphQL最大的卖点就是前端自己写查询语句，想要什么字段就取什么字段。对于页面数据需求多变、嵌套层级深的场景，确实比REST发多个请求要高效。但问题在于，这种灵活性的代价是后端解析查询语句的开销。一个复杂的GraphQL查询如果没做深度限制，前端一个请求就能把数据库查崩。

REST在这方面更可控。每个接口的返回结构固定，后端可以做精准的SQL优化和缓存。如果你的接口消费方主要是Web端和App端，数据需求相对稳定，REST的查询效率反而更好。

缓存策略差异

REST天然支持HTTP缓存。GET请求配合CDN、ETag、Cache-Control，浏览器和中间层都能缓存。GraphQL走的是POST，默认没法利用HTTP缓存层。虽然Apollo等方案提供了客户端缓存，但服务端缓存仍然需要额外开发。如果你的API有大量公共数据（商品列表、配置信息），REST配合CDN的方案成本低很多。

选择判断标准

给出三条具体的判断标准。第一，如果你的API面向多个外部团队或第三方调用方，数据需求各不相同，GraphQL的灵活性优势明显，值得投入。第二，如果团队主要是Java或Go技术栈，REST的生态和工具链更成熟，GraphQL在这些语言里的服务端库体验还差一截。第三，如果项目对安全性要求高，GraphQL的查询审计比REST复杂得多，需要额外的深度限制、复杂度分析和字段级权限控制。

还有一种务实的做法：核心业务用REST保证稳定，内部仪表盘、数据看板这种需求多变但并发不高的场景用GraphQL。两者共存，各取所长。