一. REST
核心理念是资源。服务端定义资源形式。资源的类型和获取资源的方法是紧密相关的。
REST 是多入口的,每个资源对应一个 URL,例如:http://api.test.com/books/,http://api.test.com/users/。
每个资源由后台定义好后,通过指定的一个 URL 访问(每个 URL 访问到不同的控制器)。通过向指定 URL发送 GET 请求来获取资源,或发送 POST 请求来创建或操作资源。
大部分 API 会返回 JSON 响应。例如:
// 请求
GET /books/1
GET /users/250
// 响应
{
"title": "Black Hole Blues",
"author": {
"firstName": "Janna",
"lastName": "Levin"
}
// ... more fields here
}
二. GraphQL
GraphQL 中需要定义所有资源的类型,但是不会指定对应的方法。只需要改变查询内容,前端就能定制服务器返回的响应内容。
GraphQL 是单入口的,所有的请求通过同一个 URL 进入服务器,例如:http://api.test.com/graphql。
在服务端,必须定义 Schema(模式)作为 GraphQL 请求的入口,用户的 GraphQL 请求在服务端解析后,会对应到具体的 Schema。
GraphQL 请求是这样的:query getHightScore { score } 可以获取 getHightScore 的 score 值。
也可以加上查询条件,例如:query getHightScore(limit: 10) { score }。
客户端示例:
// 查询,不加任何前缀时,默认是 query 查询。
{
user(id: 3500401) {
name,
profilePicture(size: 50) {
uri,
width,
height
}
}
}
// 响应,返回 JSON 格式的数据
{
"user" : {
"name": "Jing Chen",
"profilePicture": {
"uri": "http: //someurl.cdn/pic.jpg",
"width": 50,
"height": 50
}
}
}
服务端示例(协议实现起来挺复杂,最好直接安装现成的库,各种语言版本的服务端库在这里。):
// 定义资源
type Book {
id: ID
title: String
published: Date
price: String
author: Author
}
type Author {
id: ID
firstName: String
lastName: String
books: [Book]
}
// 定义查询
type Query {
book(id: ID!): Book
author(id: ID!): Author
}
使用 GraphQL:
GET /graphql?query={ book(id: "1") { title, author { firstName } } }
{
"title": "Black Hole Blues",
"author": {
"firstName": "Janna",
}
}
三. RESTful与GraphQL比较
【RESTful API不足】
- 前端和后端对于接口的控制权是交叉冲突的,往往一方改动不算,前端改动一个字段,连带着后端也需要改动,反之亦是
- 前端对于真正用到的字段是没有直观映像的,仅仅通过url地址,无法预测也无法回忆返回的字段数目和字段是否有效,接口返回50个字段,但却只用5个字段,造成字段冗余,扩展性差,单个RESTful接口返回数据越来越臃肿。
- API聚合问题,某个前端展现,实际需要调用多个独立的RESTful API才能获取到足够的数据
- 前后端字段频繁改动,导致类型不一致,错误的数据类型可能会导致网站出错
- 尤其是在业务多变的场景中,很难在保证工程质量的同时快速满足业务需求
案例1:比如获取用户信息/users/:id
,最初可能只有id、昵称,但随着需求的变化,用户所包含的字段可能会越来越多,年龄、性别、头像、经验、等级,等等等等。而具体到某个前端页面,可能只需要其中一小部分数据,这样就会增加网络传输量,前端获取了大量不必要的数据。
案例2:比如一个文章详情页,最初可能只需要文章内容,那么前端就调用/articles/:aid
获取到文章内容来展现就行了
但随着需求的演进,产品可能会希望加上作者信息(昵称、头像等),这时前端又需要在获取文章详情后,根据其中的作者id字段继续获取作者相关的信息,/user/:uid
然后,需求又变化了,产品希望在加上这篇文章的评论,这时前端需要继续调用/comment/:aid
来拉取评论列表
对于Web前端而言,由于ajax技术的存在,这种的请求数据方式,也就开发上稍微麻烦些,并不会造成太大的问题;但对于App来说,渲染的方式不同,必须要拉取的全部的数据之后,才能绘制界面,就会导致这个界面必须要等到所有3个RESTful接口的返回数据都拿到,才能进行绘制。
【GraphQL优点】
- GraphQL是Facebook开源的API查询语言,类似于数据库中的SQL。作为比较,RESTful API依赖于后端隐式的被动的数据约定,GraphQL更加显式,在获取数据和更新数据时更加主动,所见即所得。
- 从调用者的角度看,GraphQL更加依赖于前端,相当于是把后端的部分SQL能力转移到了前端。GraphQL可以通过查询规则,而不是通过特定的url地址来对后端的数据源进行调用,并且可以选择需要用到的字段,后端也只返回这些字段。相当于数据库SQL,但是SQL的查询对象只能是数据库,而GraphQL的查询对象是数据源,这个数据源可以是HTTP接口、数据库查询集合、静态json文件、另外一个api的数据源,特别的灵活。
- GraphQL更强大的一点是可以实现对多个数据源的调用,合并成一份完整的数据给前端使用。
策略1:所见即所得
查询的返回结果就是输入的查询结构的精确映射
策略2:减少网络请求次数
如果设计的数据结构是从属的(例如,上文中文章的作者信息),直接就能在查询语句中指定
{
article(aid:1) {
title
content
author {
uid
name
}
}
}
即使数据结构是独立的,也可以在查询语句中指定上下文,只需要一次网络请求,就能获得资源和子资源的数据(例如,上文中文章的评论信息)
{
article(aid:1) {
title
content
author {
uid
name
}
},
comment {
content,
author {
uid
name
}
}
}
策略3:代码即文档
GraphQL会把schema定义和相关的注释生成可视化的文档,从而使得代码的变更,直接就反映到最新的文档上,避免RESTful中手工维护可能会造成代码、文档不一致的问题。
策略4:参数类型强校验
RESTful方案本身没有对参数的类型做规定,往往都需要自行实现参数的校验机制,以确保安全。
但GraphQL提供了强类型的schema机制,从而天然确保了参数类型的合法性。
从Facebook最初开发GraphQL的目的,和笔者实际使用的情况而言,GraphQL还是存在一些缺点的,完全替代RESTful作为一种新的接口规范还有些为时过早.
GraphQL作为RESTful的一种辅助工具,尤其是针对前端App在复杂页面,本来要调用有上下文关系的多次RESTful请求时,采用GraphQL,只需要一次请求,就可以拿回所需的全部数据(有点JSON直出
的意思),还是可以起到非常好的效果,大大提升App的性能。
参考自: