GraphQL和RESTful的比较

引言

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

思考

GitHub的REST API已经非常完善，设计得很优秀，很多公司开发自己的REST API时都会参考GitHub的实现。

那GitHub为什么选择GraphQL？

RESTful的一些不足

• 扩展性，单个RESTful接口返回数据越来越臃肿

  比如获取用户信息/users/:id，最初可能只有id、昵称，但随着需求的变化，用户所包含的字段可能会越来越多，年龄、性别、头像、经验、等级，等等等等。

  而具体到某个前端页面，可能只需要其中一小部分数据，这样就会增加网络传输量，前端获取了大量不必要的数据。

• 某个前端展现，实际需要调用多个独立的RESTful API才能获取到足够的数据

  比如一个文章详情页，最初可能只需要文章内容，那么前端就调用/articles/:aid获取到文章内容来展现就行了

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

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

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

GraphQL的一些优点

• 所见即所得

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

  查询：

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