GraphQL和RESTful的比较

时间 2019-12-05

标签 graphql restful 比较繁體版

原文原文链接

引言

在2017年5月，Github也发布了它第四版的API，采用的正是GraphQL，而且推荐集成商在GitHub App中使用最新版本的GraphQL API v4。前端

GitHub的REST API已经很是完善，设计得很优秀，不少公司开发本身的REST API时都会参考GitHub的实现。ajax

那GitHub为何选择GraphQL？安全

扩展性，单个RESTful接口返回数据愈来愈臃肿
好比获取用户信息/users/:id，最初可能只有id、昵称，但随着需求的变化，用户所包含的字段可能会愈来愈多，年龄、性别、头像、经验、等级，等等等等。网络

而具体到某个前端页面，可能只须要其中一小部分数据，这样就会增长网络传输量，前端获取了大量没必要要的数据。数据结构
某个前端展示，实际须要调用多个独立的RESTful API才能获取到足够的数据
好比一个文章详情页，最初可能只须要文章内容，那么前端就调用/articles/:aid获取到文章内容来展示就好了工具

但随着需求的演进，产品可能会但愿加上做者信息（昵称、头像等），这时前端又须要在获取文章详情后，根据其中的做者id字段继续获取做者相关的信息，/user/:uid性能

而后，需求又变化了，产品但愿在加上这篇文章的评论，这时前端须要继续调用/comment/:aid来拉取评论列表ui

对于Web前端而言，因为ajax技术的存在，这种的请求数据方式，也就开发上稍微麻烦些，并不会形成太大的问题；但对于App来讲，渲染的方式不一样，必需要拉取的所有的数据以后，才能绘制界面，就会致使这个界面必需要等到全部3个RESTful接口的返回数据都拿到，才能进行绘制。设计

所见即所得code

查询的返回结果就是输入的查询结构的精确映射

查询：

{
    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的性能。