灵活的API查询语言——GraphQL

本文简单的介绍了 GraphQL，希望能够帮助大家对这个方便的查询语言有一个简单的认识

GraphQL 是什么

GraphQL 是一种 API 查询语言，是一个对自定义类型系统执行查询的服务端运行环境。它相当于客户端和服务器之间的中介，将客户端发来的所需数据的请求处理之后在一次请求之中就能获得符合客户端需求的响应数据。它还有个好处就是它是一种当作一种组织，管理数据的能力来使用，而不绑定在什么数据库上面，数据存在于哪里与它无关。

对比 Rest API

Rest API 是和 GraphQL 同类的用于查询的语言。Rest 把每个资源都用一个 URL 表示，访问这个 URL 就能够得到一份 JSON 格式的数据响应，但是这有一个缺点，你可能会得到与需求不相关的数据。而 GraphQL 则不会，发送过去的请求中指定了需要哪个资源，举个简单的例子，你需要这本书的作者的姓资源，那么 Rest API 会把把作者的名字也发给你，因为你是通过访问作者的信息的 URL 来获得姓的，而 GraphQL 则会只把需要的信息发过来，换句话说，需要什么资源是用户来决定的。

RPC vs REST vs GraphQL（参考资料点击这里）

在合适的时候选择合适的工具是重要的，下面则列举了在一些场景下最好使用什么工具来作为参考

1、如果是 Management API，这类 API 的特点如下：

• 关注于对象与资源
• 会有多种不同的客户端
• 需要良好的可发现性和文档
• 这种情景使用 REST + JSON API 可能会更好。

2、如果是 Command or Action API，这类 API 的特点如下：

• 面向动作或者指令
• 仅需要简单的交互
• 这种情况使用 RPC 就足够了。

3、如果是 Internal Micro Services API，这类 API 的特点如下：

• 消息密集型
• 对系统性能有较高要求
• 这种情景仍然建议使用 RPC。

4、如果是 Micro Services API，这类 API 的特点如下：

• 消息密集型
• 期望系统开销较低
• 这种情景使用 RPC 或者 REST 均可。

5、如果是 Data or Mobile API，这类 API 的特点是：

• 数据类型是具有图状的特点
• 希望对于高延迟场景可以有更好的优化
• 这种场景无疑 GraphQL 是最好的选择。

GraphQL 的查询与变更——如何查询 GraphQL 服务器
以一个查询结果为例：

{
hero {
name
}
}

该查询将会获得一个与其结构几乎一样的结果：

{
"data": {
"hero": {
"name": "R2-D2"
}
}
}

这是 GraphQL 最重要的特性，因为这样一来，你就总是能得到你想要的数据，而服务器也准确地知道客户端请求的字段。并且在GraphQL中查询是可交互的，你可以按你喜欢来改变查询，然后看看新的结果。

在查询时可以添加上参数，结果也会显得更有趣。参数可以是多种不同的类型。GraphQL 自带一套默认类型，但是 GraphQL 服务器可以声明一套自己的定制类型，只要能序列化成你的传输格式即可。

例如，有如下查询：

{
human(id: "1000") {
name
height
}
}

其结果为：

{
"data": {
"human": {
"name": "Luke Skywalker",
"height": 1.72
}
}
}

在类似 REST 的系统中，你只能传递一组简单参数 —— 请求中的 query 参数和 URL 段。但是在 GraphQL 中，每一个字段和嵌套对象都能有自己的一组参数，从而使得 GraphQL 可以完美替代多次 API 获取请求。甚至你也可以给 标量（scalar）字段传递参数，用于实现服务端的一次转换，而不用每个客户端分别转换。

更多GrophQL的类型系统请点击这里