RESTful与GraphQL

一. 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不足】

1. 前端和后端对于接口的控制权是交叉冲突的，往往一方改动不算，前端改动一个字段，连带着后端也需要改动，反之亦是
2. 前端对于真正用到的字段是没有直观映像的，仅仅通过url地址，无法预测也无法回忆返回的字段数目和字段是否有效，接口返回50个字段，但却只用5个字段，造成字段冗余，扩展性差，单个RESTful接口返回数据越来越臃肿。
3. API聚合问题，某个前端展现，实际需要调用多个独立的RESTful API才能获取到足够的数据
4. 前后端字段频繁改动，导致类型不一致，错误的数据类型可能会导致网站出错
5. 尤其是在业务多变的场景中，很难在保证工程质量的同时快速满足业务需求

案例1：比如获取用户信息/users/:id，最初可能只有id、昵称，但随着需求的变化，用户所包含的字段可能会越来越多，年龄、性别、头像、经验、等级，等等等等。而具体到某个前端页面，可能只需要其中一小部分数据，这样就会增加网络传输量，前端获取了大量不必要的数据。

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

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

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

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

【GraphQL优点】

1. GraphQL是Facebook开源的API查询语言，类似于数据库中的SQL。作为比较，RESTful API依赖于后端隐式的被动的数据约定，GraphQL更加显式，在获取数据和更新数据时更加主动，所见即所得。
2. 从调用者的角度看，GraphQL更加依赖于前端，相当于是把后端的部分SQL能力转移到了前端。GraphQL可以通过查询规则，而不是通过特定的url地址来对后端的数据源进行调用，并且可以选择需要用到的字段，后端也只返回这些字段。相当于数据库SQL，但是SQL的查询对象只能是数据库，而GraphQL的查询对象是数据源，这个数据源可以是HTTP接口、数据库查询集合、静态json文件、另外一个api的数据源，特别的灵活。
3. 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的性能。

 

参考自：

https://blog.csdn.net/kikajack/article/details/79075405

https://blog.csdn.net/qq_32614411/article/details/80912091