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呢?