本文對gRPC和REST的特征和區別進行了介紹，這可能是當今創建API最常用的兩種方法。

文章目錄

一、gRPC的介紹

二、什么是REST？

三、什么是gRPC?

四、gRPC和REST的比較

（1）底層HTTP協議

（2）支持的數據格式

（3）數據大小

（4）吞吐量

（5）定義

（6）易于采用

（7）工具支持

總結

以下將從這兩種工具的特征開始，也就是它們是什么以及提供什么功能。然后，將根據七個方面對它們進行比較，這對現代系統來說是最重要的7個類別。

其類別如下：

1. 底層HTTP協議
2. 支持的數據格式
3. 數據大小
4. 吞吐量
5. 定義
6. 易于采用
7. 工具支持

一、gRPC的介紹

當人們聽到API時，可能馬上想到REST API。然而，REST是構建API的眾多方法之一。它并不是適用于所有用例的靈丹妙藥。還有其他方法，遠程過程調用 (RPC)只是其中之一，而gRPC可能是使用RPC最成功的框架。

盡管gRPC是一種相當成熟和高效的技術，但它仍然被視為一種新技術。因此，盡管在某些用例中非常方便，但它沒有REST被廣泛采用。

本文主要介紹gRPC，并指出它可以發揮作用的用例。

二、什么是REST？

表述性狀態轉移（REST）可能是創建公開任何類型API的應用程序的最常用方法。它使用HTTP作為底層通信媒介。正因為如此，它可以從HTTP的所有優點中獲益，例如緩存。

• 客戶端-服務器通信
• 無狀態通信
• 緩存
• 統一接口
• 分層系統
• 按需編碼

REST的兩個關鍵概念是：

（1）端點：表示特定資源的唯一統一資源定位符(URL)；可以看作是通過互聯網訪問特定操作或數據元素的一種方式。

（2）資源：在特定URL下可用的特定數據塊。

此外，還有一個叫做Richardson成熟模型的描述——這是一個描述REST API中“專業性”程度的模型。它根據特定API具有的特征集將REST API劃分為3個級別(或4個級別，取決于是否將級別0計算在內)。

其中一個特征是REST端點應該在URL中使用名詞，并使用正確的HTTP請求方法來管理其資源。

• 示例：用DELETE user/1代替GET user/deleteById/1

至于HTTP方法及其相關操作，如下所示：

• GET—檢索特定的資源或資源集合。
• POST—創建一個新的資源。
• PUT—修改整個資源。
• PATCH?-特定資源的部分更新。
• DELETE—刪除指定id的資源。

成熟度模型規定的遠不止這些。例如稱為HyperMedi的概念。HyperMedia將數據的呈現和對客戶端可以執行的操作的控制結合在一起。

對成熟度模型的完整描述超出了本文的范圍。

三、什么是gRPC?

gRPC是遠程過程調用（RPC）這個相對古老的概念的另一種實現。谷歌的開發人員創建了它，這就是為什么它的名稱里有“g”的原因。它可能是處理RPC最現代和最有效的工具，也是CNCF孵化項目。

gRRC使用谷歌公司的協議緩沖區作為序列化格式，同時利用HTTP/2作為傳輸介質數據，盡管gRPC也可以使用JSON作為數據層。

• 方法：gRPC的基本構建塊，每個方法都是一個遠程過程調用，它接受一些輸入并返回輸出。它執行用所選編程語言進一步實現的單個操作。目前，gRPC支持4種方法：

① Unary：經典的請求-響應模型，該方法接受輸入并返回輸出。

② 服務器流：該方法接受消息作為輸入，同時返回消息流作為輸出。gRPC保證了單個RPC調用中的消息排序。

③ 客戶端流：該方法將消息流作為輸入，處理它們直到沒有消息為止，然后返回一條消息作為輸出。與上面類似，gRPC保證在單個RPC調用中進行消息排序。

④ 雙向流：該方法將消息流作為輸入，并將消息流作為輸出返回，有效地使用了讀和寫兩個消息流。兩個流都獨立運行，并且將消息順序保留在流級別上。

• 服務：表示一組方法，每個方法在服務中必須有其唯一的名稱。服務還描述了安全性、超時或重試等特性。
• 消息：表示方法的輸入或輸出的對象。

gRPC API定義以.proto文件的形式編寫，其中包含上述所有三個基本構建塊。此外，gRPC提供了一個協議緩沖區編譯器，它從.proto文件生成客戶端和服務代碼。

用戶可以隨心所欲地實現服務器端方法，必須堅持使用API的輸入輸出契約。

在客戶端，有一個叫做客戶端(或stub)的對象——類似于HTTP客戶端。它知道來自服務器的所有方法，只處理調用遠程過程并返回它們的響應。

四、gRPC和REST的比較

（1）底層HTTP協議

這是第一類，可能也是最重要的一類，因為它的影響也可以在其他方面看到。

一般來說，REST是基于請求-響應的，并使用HTTP/1.1作為傳輸媒介。這里必須使用不同的協議，例如WebSocket或任何類型的流或更持久的連接。

還可以實現一些簡單的代碼，使REST看起來像消息流。更重要的是，使用HTTP/1.1 REST需要每個請求-響應交換一個連接。對于長時間運行的請求，或者當網絡容量有限時，這種方法可能會有問題。

當然，可以使用HTTP/2來構建類似REST的API；然而，并不是所有的服務器和庫都支持HTTP/2。因此，其他地方可能會出現問題。

另一方面，gRPC只使用HTTP/2。它允許通過單個TCP連接發送多個請求-響應對。這種方法可以顯著地提高應用程序的性能。

• 結果：gRPC略有獲勝

（2）支持的數據格式

假設REST API使用HTTP/1.1的默認情況，那么它可以支持多種格式。

REST通常不對消息格式和樣式施加任何限制。基本上，任何一種可以序列化為普通舊文本的格式都是有效的。用戶可以在特定場景中使用最適合自己的任何格式。

在REST應用程序中發送數據的最流行格式無疑是JSON。XML排在第二位，因為有大量的較舊/遺留應用程序。

然而，當使用REST和HTTP/2時，只支持二進制交換格式。在這種情況下，可以使用Protobuf或Avro。當然，這種方法也有它的缺點，但在以下幾點中會詳細說明這一點。

同時，gRPC只支持兩種數據交換格式：

①Protobuf?—默認情況下。

②JSON—當需要與原有API集成時。

如果用戶嘗試使用JSON，那么gRPC將使用JSON作為消息的編碼格式，而使用GSON作為消息格式。此外，使用JSON需要做更多的配置。

• 結果：REST獲勝，因為它支持更多格式。

（3）數據大小

默認情況下，gRPC使用二進制數據交換格式，這顯著地減少了通過網絡發送的消息的大小：研究表明，以字節計算，大約減少了40%～50%，而從以前的一個項目中獲得的經驗表明，甚至減少了50%～70%。

以上提供了JSON和Protobuff之間相對深入的大小比較。本文作者還提供了一個生成JSON和二進制文件的工具。這樣就可以重新運行他的實驗并比較結果。

本文中的對象相當簡單。不過，一般的規則是——嵌入的對象越多，JSON的結構越復雜，它就會比Protobuf更重。50%的大小差異有利于Protobuf?是一個很好的基線。

在使用REST的二進制交換格式時，可以最大限度地減少或消除這種差異。然而，這不是最常見的，也不是最受支持的RESTful API方式，因此可能會出現其他問題。

• 結果：默認情況下，gRPC獲勝；在兩者都使用二進制數據格式的情況下，雙方為平局。

（4）吞吐量

同樣，在REST的情況下，一切都取決于底層HTTP協議和服務器。

在默認情況下，基于HTTP/1.1的REST，即使是最高性能的服務器也無法擊敗gRPC的性能，特別是當使用JSON時添加序列化和反序列化開銷時。雖然當切換到HTTP/2時，差異似乎有所減少。

至于最大吞吐量，在這兩種情況下，HTTP都是一種傳輸媒介，因此它具有無限擴展的潛力。因此，一切都取決于正在使用的工具以及對應用程序的精確操作，因為設計沒有限制。

• 結果：默認情況下為gRPC；在同時使用二進制數據和HTTP/2的情況下，gRPC略勝一籌。

（5）定義

在這一部分中，將描述如何在這兩種方法中定義消息和服務。

在大多數REST應用程序中，只是將請求和響應聲明為類、對象或特定語言支持的任何結構。然后，依靠提供的庫來序列化和反序列化JSON/XML/YAML或任何需要的格式。

此外，目前正在努力創建能夠根據Swagger的REST API定義用所選編程語言生成代碼的工具。然而，它們似乎是在alpha版本中，所以仍然可能會出現一些錯誤和小問題，這將使它們難以使用。

REST應用程序的二進制格式和非二進制格式之間幾乎沒有區別，因為這兩種情況下的規則大致相同。對于二進制格式，只是以特定格式所需的方式定義所有內容。

此外，可以通過來自底層庫或框架的方法或注釋來定義REST服務。該工具還負責將其與其他配置一起向外部世界公開。

在gRPC的情況下，將Protobuf作為默認的并且事實上是編寫定義的唯一方式。必須在.proto文件中聲明所有內容：消息、服務和方法，所以事情非常簡單。

然后使用gRPC提供的工具生成代碼，只需要實現自己的方法。在那之后，一切都應該按預期工作。

此外，Protobuf支持導入，因此能夠以一種相當簡單的方式將設置擴展到多個文件。

• 結果：在這里沒有贏家，給出的描述和建議是，選擇最適合自己的方法。

（6）易于采用

在這一部分中，將比較現代編程語言中對每種方法的庫/框架支持。

本文作者表示，在他作為軟件工程師的職業生涯中，遇到的每種編程語言(Java、Scala、Python)都至少有3個主要的庫/框架用于創建類REST應用程序，更不用說將JSON解析為對象/類的庫了。

此外，由于REST默認使用人類可讀的格式，因此對于新手來說，它更容易調試和使用。這也會影響交付新特性的速度，并幫助用戶應對代碼中出現的錯誤。

長話短說，對REST風格應用程序的支持至少非常好。

在Scala中，甚至有一個叫做Tapir的工具。Tapir允許用戶抽象HTTP服務器，并編寫可用于多個服務器的端點。

gRPC本身為超過8種流行的編程語言提供了客戶端庫。這通常就足夠了，因為這些庫包含了制作gRPC API所需的所有內容。此外，一些庫為Java(通過Spring Boot Starter)和Scala提供了更高的抽象。

另一件事是，REST如今被認為是一個世界性的標準和構建服務的切入點，而RPC和gRPC，特別是，盡管在這一點上有點過時，但仍然被視為一種新奇事物。

• 結果：REST被更廣泛地采用，并且有更多的庫和框架。

（7）工具支持

以上已經介紹了庫、框架和一般市場份額，所以在這一部分中介紹圍繞這兩種風格的工具。它意味著用于測試、性能/壓力測試和文檔的工具。

①自動化測試

首先，在REST的情況下，用于構建自動化測試的工具被構建到不同的庫和框架中，或者是為了這個唯一目的而構建的獨立工具，比如REST-assured。

在gRPC的情況下，可以生成一個stub并將其用于測試。如果想要更嚴格，可以將生成的客戶端作為一個單獨的應用程序使用，并將其用作對實際服務進行測試的基礎。

關于gRPC的外部工具支持，需要知道：

• Postman程序對gRPC的支持。
• 在IDE中使用的JetBrains HTTP客戶端也可以通過一些最低配置來支持gRPC。
• 結果一：REST獲得勝利。然而，gRPC的情況似乎有所改善。

②性能測試

在這里，REST具有顯著的優勢，因為像JMeter或Gatling這樣的工具使REST API的壓力測試變得相當容易。

不幸的是，gRPC沒有這樣的支持。在當前的Gatling版本中包含了gRPC插件，所以情況似乎正在好轉。

然而到目前為止，只有一個名為ghz的非官方插件和庫。這些都很好；它只是與REST的支持級別不同。

• 結果二：REST的勝利；然而，gRPC的情況似乎有所改善。

③文檔

在API文檔方面，隨著OpenAPI和Swagger在整個行業被廣泛采用并成為事實上的標準，REST再次取得了勝利。幾乎所有用于REST的庫都能夠以最小的努力或開箱即用的方式公開Swagger文檔。

不幸的是，gRPC沒有這樣的文檔。

然而，問題是gRPC是否需要這樣的工具。gRPC在設計上比REST更具描述性，因此可能需要其他文檔工具。

一般來說，帶有API描述的.proto文件比負責編寫REST API代碼的代碼更具聲明性和緊湊性，因此可能不需要gRPC提供更多文檔。

• 結果三：REST的勝利。然而，關于gRPC文檔的問題是開放的。

④總體結果

這是REST的一次重大勝利。

總結

以下是gRPC和REST比較的最終得分表。

得出的結論是：gRPC和REST的比較結果平分秋色，各有三場勝利，沒有明顯的贏家。

因此沒有什么靈丹妙藥，用戶只需要考慮哪些類別可能對應用程序最重要，然后選擇在大多數類別中獲勝的方法。

本文作者表示，如果可以的話，他會嘗試使用gRPC，因為gRPC在他的上一個項目中運行得非常好。它可能是比原有的REST更好的選擇。

善用工具

成功的前端工程師很會善用工具，這些年低代碼概念開始流行，像國外的 Mendix，國內的 JNPF，這種新型的開發方式，圖形化的拖拉拽配置界面，并兼容了自定義的組件、代碼擴展，確實在 B 端后臺管理類網站建設中很大程度上的提升了效率。

開源地址：JNPF體驗中心

代碼量少，系統的穩定性和易調整性都會得到一定的保障。基于代碼生成器，可一站式開發多端使用 Web、Android、IOS、微信小程序。代碼自動生成后可以下載本地，進行二次開發，有效提高整體開發效率。同時，支持多種云環境部署、本地部署給予最大的安全保障，可以快速搭建適合自身應用場景的產品。

原文標題：gRPC vs REST：Comparing Approaches for Making APIs??????