既生瑜何生亮, 脸书倡导的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等各大平台同步上线,敬请期待关注,欢迎洽谈合作相关事宜。
作者简介:
从事软件开发研究二十多年。
先后在如下地区工作:山东,北京,德国斯图加特,新加坡,加拿大温哥华。
个人爱好:
练拳,好好学习,天天向上。