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

作者：小姐姐養的狗 2022-08-02 19:03:19

網絡網絡優化

Rest是最常用的API交互手段，SpringBoot對其進行了高度的集成。它通過語義化的URL，使用最通用的HTTP協議，完成無狀態的請求交互。

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。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。

責任編輯：武曉燕來源：小姐姐味道