REST API 还是 GraphQL？

前言

说到 API 设计，GraphQL 和 RESTful API 是当前最主流的两种选择，各自有其独特优势与挑战。

有幸的是，我上家公司的时候，使用的就是 GraphQL，而在上上家使用的是 RESTful API，

今天我就结合我的经验，来聊聊到底该如何选择！

正文

GraphQL 优劣势

GraphQL 是 Facebook 推出的声明式查询语言，它的最大优势在于灵活和高效。

你只需要请求自己需要的字段，减少冗余数据传输，可以很大程度上优化性能。

GraphQL

另外，相比 REST 的多次接口调用，GraphQL 支持聚合请求，有效减少 HTTP 请求次数。

聚合查询

还有个好处是，它通过 Schema 统一前后端对接口结构的认知，配合类型提示、Mock 能力，大大提升开发体验。

比如借助代码生成工具 Apollo 或 Relay，可以自动生成对应的查询代码！

Apollo

最后，天然支持 Subscription，适用于聊天、通知等实时性强的业务场景！

当然，它的劣势也很明显：

不像 REST 可以使用 HTTP 缓存，GraphQL 的缓存需要借助 Apollo 等第三方库维护！

前面提到，虽然可以聚合请求，但是所有请求集中在一个端点，可能会成为系统瓶颈，尤其在高并发场景下！

RESTful API 优劣势

RESTful API 是目前最广泛使用的接口规范，基于 HTTP 协议，使用资源路径和请求方法组合完成数据操作。

它的设计清晰直观，GET/POST/PUT/DELETE 等操作语义明确。

增删改查，一目了然

而且生态成熟，社区和工具链完善，日志、监控、安全机制等配套方案多。

最重要的是支持 HTTP 缓存机制，天然支持浏览器或中间层缓存，提升接口性能！

而且通过 Postman、curl 等工具即可快速测试和验证接口。

但它也存在一些问题：

比如，请求冗余，无法控制字段粒度，常常返回大量用不到的数据！

多端聚合困难，遇到复杂业务需要多次请求多个接口，增加开发成本。

还有就是扩展性不如 GraphQL，对于需要动态字段、自定义响应结构的场景，REST 显得不够灵活！

最后

GraphQL 和 REST 各有千秋，关键在于选择适合自己团队和项目的方案。小团队、简单业务选 REST，快准稳；复杂系统、多端协作选 GraphQL，灵活高效。不被技术趋势绑架，做最合适的技术决策，才是架构的本质。

今天的分享就这些了，感谢大家的阅读，如果文章中存在错误的地方欢迎指正！