GraphQL和RESTful的比较
引言
在2017年5月,Github也发布了它第四版的API,采用的正是GraphQL,并且推荐集成商在GitHub App中使用最新版本的GraphQL API v4。
思考
GitHub的REST API已经非常完善,设计得很优秀,很多公司开发自己的REST API时都会参考GitHub的实现。
那GitHub为什么选择GraphQL?
RESTful的一些不足
-
扩展性,单个RESTful接口返回数据越来越臃肿
比如获取用户信息
/users/:id
,最初可能只有id、昵称,但随着需求的变化,用户所包含的字段可能会越来越多,年龄、性别、头像、经验、等级,等等等等。而具体到某个前端页面,可能只需要其中一小部分数据,这样就会增加网络传输量,前端获取了大量不必要的数据。
-
某个前端展现,实际需要调用多个独立的RESTful API才能获取到足够的数据
比如一个文章详情页,最初可能只需要文章内容,那么前端就调用
/articles/:aid
获取到文章内容来展现就行了但随着需求的演进,产品可能会希望加上作者信息(昵称、头像等),这时前端又需要在获取文章详情后,根据其中的作者id字段继续获取作者相关的信息,
/user/:uid
然后,需求又变化了,产品希望在加上这篇文章的评论,这时前端需要继续调用
/comment/:aid
来拉取评论列表对于Web前端而言,由于ajax技术的存在,这种的请求数据方式,也就开发上稍微麻烦些,并不会造成太大的问题;但对于App来说,渲染的方式不同,必须要拉取的全部的数据之后,才能绘制界面,就会导致这个界面必须要等到所有3个RESTful接口的返回数据都拿到,才能进行绘制。
GraphQL的一些优点
-
所见即所得
查询的返回结果就是输入的查询结构的精确映射
查询:
{ user(uid:1) { uid name } }
返回:
{ "data": { "user": { "uid": "1", "name": "xxx" } } }
-
减少网络请求次数
如果设计的数据结构是从属的(例如,上文中文章的作者信息),直接就能在查询语句中指定
{ article(aid:1) { title content author { uid name } } }
即使数据结构是独立的,也可以在查询语句中指定上下文,只需要一次网络请求,就能获得资源和子资源的数据(例如,上文中文章的评论信息)
{ article(aid:1) { title content author { uid name } }, comment { content, author { uid name } } }
-
代码即文档
GraphQL会把schema定义和相关的注释生成可视化的文档,从而使得代码的变更,直接就反映到最新的文档上,避免RESTful中手工维护可能会造成代码、文档不一致的问题。
-
参数类型强校验
RESTful方案本身没有对参数的类型做规定,往往都需要自行实现参数的校验机制,以确保安全。
但GraphQL提供了强类型的schema机制,从而天然确保了参数类型的合法性。
使用心得
从Facebook最初开发GraphQL的目的,和笔者实际使用的情况而言,GraphQL还是存在一些缺点的,完全替代RESTful作为一种新的接口规范还有些为时过早.
GraphQL作为RESTful的一种辅助工具,尤其是针对前端App在复杂页面,本来要调用有上下文关系的多次RESTful请求时,采用GraphQL,只需要一次请求,就可以拿回所需的全部数据(有点JSON直出
的意思),还是可以起到非常好的效果,大大提升App的性能。