vlambda博客
学习文章列表

导读： RESTful API已经发展了很多年，有一些优点也有缺点，而“后起之秀”GraphQL有哪些优势，能够替代掉 REST API吗？

在2000年，计算机科学家 Roy Fielding博士提出一种新的软件体系结构的论文：代表性状态，也就是REST。

RESTful API允许Web客户端通过一组预定义的无状态操作访问相关资源。

REST对资源URI的请求是以JSON方式发送，因此比SOAP解决方案更简单，后者曾经引领过一段时间潮流，请求发送后是以比较难理解的XML格式返回。

因为RESTful的简单性旋即成为网站和App API的标准，直到最近几年，才出现了确定的竞争对手，那就是GraphQL.

该语言是2012年的Facebook用来构建移动应用的产品，在2015年开源，至此它的欢迎程度一直在增长。

本文就介绍REST和GraphQL之间的区别和各自优缺点。

多个节点和一个节点

REST API具有多个节点，或也可称为多个路径，对外公开不同的HTTP方法的URI。如POST /user {name,'Roy'} ，它由HTTP的POST方法，向路径 /user 发出一个组合 name:Roy 的报文请求。

而GraphQL API则只有一个节点 /graphql 。所有资源请求均重定向到此节点。 此外，GraphQL API只需要POST一种HTTP方法（也有启动GET查询的选项）。

比如这样的查询示例：

/graphql?query={user{name}}

query是操作类型，user是操作节点，name是你想要返回的请求字段。这里请求主体是必填的，它是你具体指定要返回的内容。

接下来我们来了解REST和GraphQL的第二大区别。

内容过度获取与获取不足

REST API容易出现过度获取或者不足的情况。过度获取，指的是 REST API在单个节点发回全部的数据，而不管你是不是都需要。比如下面的示例，将收到/movie/12 节点关联的所有字段：

如果使用GraphQL,就可以使用构建模式，让客户端更加具体。以下是和上面例子功能相同，但构建的是GraphQL模式的方式：

请求GraphQL后，数据将是什么样的结果？请来看一下。

可以看到，我们拿到了自己想要的东西，没有多也没有少。没有过度获取的原因是，在客户端查询主体中明确指定了想要的内容。

REST API还有一些缺点，它需要对相关资源进行多次查询和返回操作。比如查找博客文章以及作者信息，可能需要使用HTTP GET方法进行两次，因为存在两个节点：/post/1和/users/1。

我们使用GraphQL,可以在单一请求中明确要求某项信息。这种精确性在客户端被隐藏，而在后端GraphQL要多一些复杂性处理，用来管理前端的模式以及查询。

关于版本控制

由于时间和资金的控制，任何API的第一个版本会有一些粗焅。比如REST API的v1版本，请求/users 节点时会返回如结果“

当开发人员查看API时，他们意识到这个role 值时可能并不理解是什么意思，它没有语义化。后端API可以增加一个选项，在节点处理增加一个新字段，以解释该字段的含义，如下所示：

是的，它不会破坏任何客户端查询，但是已经让REST API的过度获取。此外，后端的开发者可能会更改role字段的类型：

这种情况相当于创建了API的第2个版本，并且还要公布给调用者。这种微小的改动要发布个新版本也不偿失，只有v1中有足够的修改价值才创建新版本。

而GraphQL则是无版本的。假设我们已经在GraphQL中定义了一个与以上示例一样的字段类型，是两个整型数据：

其返回的结果与REST的v1相同，开发人员得出的是相同的结果。这个role字段的整型值没有语义化，后端开发人员想修改它。

开发者可以选择添加一个新字段，这个字段与rest api的解决方案相同。但是，与rest api的区别是，graphql不会过度获取，没有多余的缺点。

最后，开发者仍选择弃用role字段，让客户端开发者了解不需要用该字段。另外，由于graphql能够确切的了解客户端正在寻找的信息，因此可以仅通知针对使用不推荐字段的客户端开发者进行更改，而不是针对所有的客户端。

小结

来总结一下内容。rest有很多个节点，而graphql只有一个节点。rest api容易出现过度获取和获取不足的情况，而graphql则不会出现此情况。

话虽如此，rest api可以使用http的内容类型、缓存以及状态码、媒体控件，如果开发者非常熟http的接收和发送，还有很多功能强大的特性。

可以确定的是，GraphQL相对于REST的优势更明显，正在成为API开发的首选方式。

相关阅读：