使用 GraphQL，你可以将你所有的业务建模为图。
中文官网：http://graphql.cn/
REST是一种古老的面向服务端和客户端的架构风格。它定义了一系列严格的构建API的原则，用简单的方式描述资源，并认为大部分时候违背这些原则会让软件的扩展性受限。随着服务端SOA和客户端Ajax的崛起，通信扩展问题变得越来越重要，REST得以广泛被运用。
在MicroService逐渐流行的今天，RESTful API已经成为主流。不过随着前端和移动端的迅猛发展，REST也面临严峻挑战。
REST API存在问题：
-
资源分类导致性能受限。前端的效率主要来源于http请求
-
在现代场景中难于维护。虽然REST的目标是易于维护和扩展，但在Web前端/客户端领域，它的表现并没有想象得那么好。我们经常说最明显的Code smell就是重复。
-
缺乏约束。对REST来说，不同版本之间的兼容能力非常弱小。
-
严格，抽象，但并不能解决客户端问题。我们经常可以在网上看到互相指责的文章和讨论，基本上都是一方列举出自己使用RESTful API遇到的实际问题，而另一方认为前者实际应用违反了哪条REST原则，因此不是RESTful API。
GraphQL是什么？
image
GraphQL是一个查询语言，由Facebook开发，用于替换RESTful API。服务端可以用任何的语言实现。
GraphQL优势：
-
需求驱动。可以减少了沟通成本。
-
一次请求复杂数据。
-
静态类型。
-
兼容多版本。
GraphQL也存在一些潜在的问题，如安全问题，需要重新思考Cache策略等。
那么 GraphQL 与 RESTful 的具体区别有什么呢？我觉得主要是两点。
- 入口 (entry point)
RESTful 的核心理念在于资源 (resource)，且讲究一个 RESTful 接口仅操作单一资源；因此在你使用 RESTful 时，会设计出大量的接口。
GraphQL 是单一入口，一般配置在 [host]/graphql/，所有的资源都从该入口通过 GraphQL 的语句获取或修改（当然 GraphQL 亦支持多入口，但显然多入口的数量也远小于 RESTful）。
- 所见即所得
查询的返回结果就是输入的查询结构的精确映射
查询：
{
hero {
name
}
}
返回：
{
"data": {
"hero": {
"name": "R2-D2"
}
}
}
- 减少网络请求次数
如果设计的数据结构是从属的，直接就能在查询语句中指定。
{
hero (id: "10"){
name
# 查询可以有备注！
friends {
name
}
}
}
查询结果：
{
"data": {
"hero": {
"name": "R2-D2",
"friends": [
{
"name": "Luke Skywalker"
},
{
"name": "Han Solo"
},
{
"name": "Leia Organa"
}
]
}
}}
即使数据结构是独立的，也可以在查询语句中指定上下文，只需要一次网络请求，就能获得资源和子资源的数据。
query {
hero {
name
}
droid(id: "2000") {
name
}
}
4 代码即文档
GraphQL会把schema定义和相关的注释生成可视化的文档，从而使得代码的变更，直接就反映到最新的文档上，避免RESTful中手工维护可能会造成代码、文档不一致的问题。
5 参数类型强校验
RESTful方案本身没有对参数的类型做规定，往往都需要自行实现参数的校验机制，以确保安全。
但GraphQL提供了强类型的schema机制，从而天然确保了参数类型的合法性。
获取更多内容请关注微信公众号豆志昂扬:
- 直接添加公众号豆志昂扬；
- 微信扫描下图二维码；
网友评论