高手，云集在于REST、gRPC 和 GraphQL之间!

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留此信息。

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提供了多种数据传输模式。

1. 类似于Rest的HTTP的一问一答模式；

2. Client-Streaming 客户端发送数据是流的方式，然后以特定信息结尾，然后Server返回结果；

3. Server-Streaming Client请求了服务端，服务端持续发送数据到Client，直到通知它结束；

4. 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。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。

推荐阅读：

1. 玩转Linux
2. 什么味道专辑

3. 蓝牙如梦
4. 杀机！
5. 失联的架构师，只留下一段脚本
6. 架构师写的BUG，非比寻常
7. 有些程序员，本质是一群羊！