Rest、GraphQL、gRPC,是目前对Web暴露API常用的三种组织方式。

每当看着这些名词,我都会进入选择困难症。这些丰富多彩的协议填满了我们的工具箱,同时也抛出了一个难题:如果我想要自己的程序健康长久,就不得不了解它们到底是什么东西。

这很让人讨厌,因为它们就像是螺丝螺母的型号,你做的工作只不过是从一堆零件里挑合适的出来,让它们配对,并让它们组合成你想要的功能。


(资料图片)

很无趣,也非常没有价值。但看在钱的面子上,又不得不学。本文就是让你快速进行选择,不拖泥带水,赶紧完成工作,喝杯茶也比瞎纠结有趣的多。

Rest

Rest是最常用的API交互手段,SpringBoot对其进行了高度的集成。它通过语义化的URL,使用最通用的HTTP协议,完成无状态的请求交互。

Rest是Restfull的简称,使用HTTP的POST、GET、 PUT、 PATCH 和DELETE来定义对资源的操作。

虽然有这么的操作意义,但在平常的使用中,我们习惯只使用它的POST和GET方法,对应在Spring里就是@GetMapping和@PostMapping注解。没别的原因,只因为Rest看似很强大,但在企业开发中曲线相对较高,很多聚合资源和复杂的操作,根本无法抽象成资源。

但Rest变种也算Rest,它依然是使用最广泛的模式。

选择Rest的原因是因为它的生态太好了。从Ruby到Java、从Golang到Rust,几乎没有语言不支持Rest。如果你想要开发一个Web系统,那几行代码,非常容易的就能把你的API暴露出去。而且,它与网关的集成度非常高,各种负载均衡组件对HTTP的协议可以说是炉火纯青,如果你选择它的话,真的是非常的省事。

但是,Rest也意味着效率低下。由于它要兼容HTTP1.0,频繁的短链接也造成了资源的浪费。即使是长链接,HTTP臃肿的体积也让它在追求高性能的场景中稍逊一筹。加上它是无状态的,如果你想传递一些伴随着用户的数据比如JWT Token,那么你不得不放在HTTP Header或者Cookie中,这加重了整体的传输负担。

总之,Rest是一个快速的开始,但在高性能、有状态的场景下,你不得不选择其他。

gRPC

gRPC当然是Google的作品,因为它传输的数据就是google另外一个产品protobuf所编码的。提到gRPC就不得不提到thrift,它们是一样的东西。但由于google的光环,gRPC更加流行。

gRPC的开发就不像Rest那么灵活,它需要你定义一份合同,然后在client和server端同时引用和传输它。

有了这份合同,就可以压缩数据。比如我们常用的json,其实冗余信息特别多。如果把json的字段使用固定的int代替,或者放在固定的位置进行传递,那么字段名称就根本不需要占用那么大的空间。

gRPC提供了多种数据传输模式。

类似于Rest的HTTP的一问一答模式;Client-Streaming 客户端发送数据是流的方式,然后以特定信息结尾,然后Server返回结果;Server-Streaming Client请求了服务端,服务端持续发送数据到Client,直到通知它结束;Bidirectional Streaming 双工通道,那就是普通的TCP链接了,全部是流的方式;

gRPC发展了这么多年(2016),对负载均衡的支持也非常好。相对于传统的Rest,它使用HTTP2来传输数据,减少了一问一答的等待,减少了链接的占用。

如果你在搞物联网,或者一些弱网环境的数据收集,这种高压缩比的数据定然让你事半功倍。当然,如果你的微服务体系追求较高的性能,结果Rest就占了一半,那么gRPC是你的不二选择。

当然,弱点也是有的。那就是调试的时候,不如HTTP的生态全面,各种自动化工具缺乏,二进制也通常会让人头晕目眩。

GraphQL

GraphQL也比较年轻,到了2015年才诞生,它规定了一种只取“所需要”数据的能力。

在传统的Rest请求上,访问特定的URL,你会获得相对固定的结果。不管返回的数据里有多少无用的字段,Rest请求都会把请求吐给你。

GraphQL的客户端可以决定取出哪些数据,甚至是取数据的方式和格式--也就是只取它所需要的数据,而不会产生过多的无用数据。

Github就是GraphQL的集大成者。在https://docs.github.com/en/graphql上,详细的列出了这些接口。

下面就是一个典型的带有变量的查询语法。可以看到,这使得请求端比如Js有了类似编程的能力。

query($number_of_repos:Int!) { viewer { name repositories(last: $number_of_repos) { nodes { name } } }}variables { "number_of_repos": 3}

当然它的弱点也是显而易见的。相对于直接请求某个地址,这些查询语句使得请求的构造变的复杂,学习曲线相对陡峭。

对于复杂的资源查询,尤其是字段非常多,且层次非常深的资源查询,GraphQL不失为一种好的方式。

End

以上就是这三种主要方式的简单介绍。目前,Rest毫无疑问是使用最多的,原因就是因为简单;gRPC有着迅猛的发展势头,尤其在微服务领域已经得到广泛应用;GraphQL很复杂,当然对复杂的业务数据来说是一个好的工具。

当你的业务纯粹是功能为主,访问量一般,那就毫无疑问的使用Rest来快速实现,拿钱完事;如果你的业务对性能要求很高,交互方式上又有流的表现形式,那可以选择gRPC,这一般发生在项目初期,否则还是遵循公司的基础建设为主;GraphQL就相对比较高级了,引入它很痛,周期也较长,是否使用它来组织数据,就看你的决心了。

但无论如何,比起绣花针刺大象,永远不要使用大炮打蚊子。那可能轰不着蚊子,而会炸了自己。

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。

标签: Rest