既生瑜何生亮， 脸书倡导的GraphQL是什么？跟Rest API 有什么可比性？
大家好，这一期呢，我们来说一下GraphQL。
这是一个比较新的概念。如果你是第1次碰到这个概念的话，一般都会问:
GraphQL是什么？
干什么用的？
它跟Rest API有什么关系？
用了它是不是就可以放弃Rest API了？
先说说它的起源。GraphQL是由Facebook也就是脸书， 设计出来的。它的原始定义包含如下模棱两可的两点:
它是一个查询数据的语言理念，
使用灵活机制，为客户端提供可靠的数据。
上面这两点的意思就是说，GraphQL可以提供数据，它很牛B。
这门技术的主要核心思想是让数据查询变得智能化。
举个例子说， 我们在开发和使用Rest API的时候， 比方说get，我们获取到的数据，一般来说要不多了，多了没关系，无非就是多占一些空间和流量， 要不就不够，那我们需要再调用其他的API再取一次。
这个例子是说Rest API的执行模式是比较机械的，没有智能化可言。
我们来探讨一下Rest API的设计模式，比如说常用的crud。
我们看一下这种api一个例子:
/player
/player/:id
/game
等等。
因为RestAPI力求简单, 一般来说，一个API只做一种资源的处理，就像上面的三个API的例子那样。
player api通过传输ID来获取player的所有信息。尽管大多数时候，我们只需要这些信息中的1/3，甚至更少。
一般来说，这种模式问题并不大。我们一般的项目都是小型的，中型的，顶多是大型规模的项目。
但是如果像Facebook这样的网站，积少成多，一点小小的冗余数据就会变得非常庞大。同样的，多调一次API，也会导致网站传输负担的加重。
为了解决这个问题，GraphQL就应运而生了。解决上面问题的方式就是创建一个API来选择性的获取你需要的那部分数据。
用一个生活中的例子做个对比，更容易理解。
Rest API就像自助餐。你去吃自助餐的时候，要把这顿饭吃完吃好，你需要去取好几次食材。
GraphQL就像去餐馆点餐，点餐的话，就不需要像自助餐那样去多次获取食材，我们会叫服务员过来指定我们想要的食材，大多数时候就是一次获取，除非你没吃饱，还想加餐，当然了，也有时候需要打包。
在程序处理中，加餐和打包的情况我们可以忽略。因为作为程序设计者，你可以避免这种情况。
说到这里，我们看到了一个很有意思的现象。本质上，Rest API和GraphQL没有区别。因为你可以把Rest API设计的很聪明，可以做到像GraphQL的理念那样去获取数据。这个时候你的Rest API就是GraphQL了。
下面我们来看一个实际的GraphQL的例子。
{
user(id:3){
name,
teamName
}
}
那根据这个GraphQL的要求我们返回如下数据:
{
"data":{
"user":{
"name": "张三",
"teamName": "北京队"
}
}
}
。
欢迎关注一起学习讨论，共同进步。
十年内计划写出超过三千六百篇文章，与超过三万名读者互动。
这些文章会在今日头条，知乎，简书，微博，微信公众平台，阿里大鱼号，Medium等各大平台同步上线，敬请期待关注，欢迎洽谈合作相关事宜。
作者简介：
从事软件开发研究二十多年。
先后在如下地区工作：山东,北京,德国斯图加特，新加坡，加拿大温哥华。
个人爱好：
练拳，好好学习，天天向上。
