01 序言
1 REST VS GraphQL
REST
是一种API
的风格规范,而GraphQL
是一种API
查询语言,总的来说就是这2个都是用来做API
的,最终的目的都是一样的。那么已经有好理解简单的
REST
为什么要用GraphQL
呢?
REST
好理解是它把要访问的链接看成是一个有层级的单一的资源,url
能描述资源所在的层级关系,而通过不同的请求方式对该资源实现CURD
的操作,
从而实现API
功能,如:
REST API | body参数 | 描述 |
---|---|---|
GET http://localhost/authors | 无 | GET 方式为读取,资源为/authors 是作家意思且复数示意作家列表,这个接口的 意思就 是获取一个作家的列表 |
GET http://localhost/authors/1/posts | 无 | 资源层级位置为/authors/1/posts , 意为读取 id 为1的作家名下的文章数列 |
POST http://localhost/authors | {...} | (解释同上, 为新增操作) |
PUT/PATCH http://localhost/authors/1 | {...} | (解释同上, 为修改操作) |
DELETE http://localhost/authors/1 | 无 | (解释同上, 为删除操作) |
REST API在线测试沙盒
那GraphQL
又是如何实现API
的功能呢?GraphQL
本质是种强类型的查询语言,只不过它的查询化为3种,为分别为:
方式 | 说明 |
---|---|
query | 查询操作, 相当于REST 的GET |
mutation | 变动操作, 相当于REST 的PUT/PATCH, DELETE, POST ,都放在这里操作 |
subscription | 订阅操作,可以理解为订阅一个资源,如果 后端有变动,后端将通过 websocket 方式通知过来,这也是 REST 欠缺的 |
GraphQL在线测试沙盒
- Query示例
- Mutation示例
- Subscription示例
小结: REST
能实现的功能,GraphQL
也能实现,还多了个订阅功能。另外REST
的链接是有层级关系的,而GraphQL`没有,如果接口有上下层级关系的可能需要借助对应的接口的文档来帮助理解。
2 GraphQL的优势
优势1: 直观地获取到期望的数据
REST API
获取的数据并没任何的约束,不看说明文档和直接测试看看,是无法确定会返回什么数据的,如以下是一个GET
请求和响应的json
数据的示例:
[ { uid: "1", title: "狂人日记", id: "1", chapters: [ { id: "1", title: "狂人日记", content: "虚..., 别出声,他们在吃人..." } ], updatedTime: "2021-11-17T11:56:05.106Z" } ]
虽然REST API
可以拿到数据,但能返回什么样的数据是客户端这边无法预测到,而开发者往往为了兼顾多种设备,而在写接口时会返回大量对单个
设备来说不必要的数据,造成阅读的不便和请求加载数据过于缓慢。而GraphQL
而能很好地实现解决一问题。
GraphQL
是一门应用于API
的强类型查询语言。客户端声明要查询哪些数据,服务端响应后并返回客户端期望的数据,它返回的数据完全符合客户端的查询
预期,不会多也不会少。如,
资源的订阅
自定义响的参数别名
只有一个版本
直接测试
稳定而写测试是很常规的做法,但这在写REST API
的集成测试时会是个灾难。
想要对以上示例接口GET https://notedemo.wuchuheng.com/posts
进行集成测试,首先需要断言返回的数据是一组
数组对象,然后还要遍历每个对象并对每个字段进行断言,如:有id
字段且为integer
类型,有title
字段且为string
类型等等,这还只是
对一个接口的简单数据进行测试。 但如果是GraphQL
呢?