灵活的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（参考资料点击这里）

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

一、若是是 Management API，这类 API 的特色以下：

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

二、若是是 Command or Action API，这类 API 的特色以下：

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

三、若是是 Internal Micro Services API，这类 API 的特色以下：

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

四、若是是 Micro Services API，这类 API 的特色以下：

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

五、若是是 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）字段传递参数，用于实现服务端的一次转换，而不用每一个客户端分别转换。