🚀 REST API 还是 ✈️ GraphQL ❓

前言

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

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

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

往期精彩推荐

正文

GraphQL 优劣势

GraphQLFacebook 推出的声明式查询语言,它的最大优势在于灵活和高效。

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

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

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

比如借助代码生成工具 ApolloRelay,可以自动生成对应的查询代码!

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

当然,它的劣势也很明显:

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

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

RESTful API 优劣势

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

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

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

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

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

Apifox Swagger Postman

但它也存在一些问题:

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

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

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

最后

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

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

往期精彩推荐

相关推荐
谭光志9 小时前
Vibe Coding 时代,程序员该何去何从
前端·后端·ai编程
仿生狮子11 小时前
别再说“全栈”了,AI 时代团队只认这 5 种人
前端·人工智能·后端
kyriewen11 小时前
AI 写的 React 组件,合并前必查的 6 个坏味道——每个都有代码对比
前端·javascript·react.js
Highcharts.js12 小时前
软件开发公司为什么选择 Highcharts?
前端·前端框架·echarts·数据可视化·技术选型·highcharts·图表工具
阿祖zu12 小时前
企业 AI 转型之痛,个人提效十倍不止,组织效率仍止步不前?
前端·aigc·agent
摇滚侠14 小时前
SpringBoot3+Vue3 全套视频教程 45-51
前端·javascript·vue.js
酸梅果茶14 小时前
【6】lightning_lm项目-LIO 前端 -点云预处理模块
前端·slam
Hilaku14 小时前
前端大裁员背后的恐慌:我们还剩什么底牌?
前端·javascript·程序员
咖啡无伴侣15 小时前
unplugin-auto-import 使用详解+面试高频考点
前端·架构
搬砖记录员15 小时前
录屏文件打不开?H.265兼容性踩坑与4种实战方案
前端