翻譯：REST 和 gRPC 詳細比較

譯者注：在微服務架構設計，構建API和服務間通信技術選型時，對 REST 和 gRPC 的理解和應用還存在知識盲區，近期看到國外的這篇文章：A detailed comparison of REST and gRPC，將二者進行了詳細對比，周末有時間翻譯過來，希望能幫到大家！

很長一段時間以來，REST是構建API的唯一“標準”，近年來，出現了新的替代方案，2015年，臉書發布了GraphQL，2016年谷歌緊隨其后發布了gRPC，被廣泛使用，在本文中，將關注gRPC，并將其與REST進行比較，

概述

下表將概述本文討論的要點，并顯示 REST 和 gRPC 真正的亮點，

標準化

REST 缺點之一是缺乏標準化，與其說 REST 是一個API標準，不如說是一種范式，許多人在談論它時都有不同的含義，對大多數人來說，術語“REST API”是基于HTTP的JSON API；對于其他規范，REST 可以與某些規范（如：HATEOAS或 JSON:API）互換使用，

REST這個術語甚至與HTTP無關，在使用 REST API 時，可能會導致很多混亂，例如，即使沒有明確定義，使用者可能會期望某些 REST API 端點的冪等性或可快取性，

相比之下，gRPC定義得很好，例如，基于 HTTP/2 的gRPC實作非常詳細，

基本差異

REST 和 gRPC 的范式并不相同，

REST 一切都以資源為中心，這些資源可以被檢索和操作，如果以圖書作為示例資源，REST API通常會提供以下端點：

• GET /books ：檢索所有書，可帶有篩選和分頁結果的引數
• GET /books/{id} ：檢索指定ID書
• POST /books ：創建書
• DELETE /books/{id} ：洗掉書

大多數基于 HTTP 的 REST API 都遵循這種模式，這很好，但某些情況很難表示為 REST API，例如，如果想創建多本書，而不想為每本書重復呼叫 POST/books（出于性能、冪等性或其他原因），該怎么辦？是否應該創建 POST/books/batch 端點？這還是“RESTful”嗎？雖然在技術上容易解決，但開發人員之間經常會進行長時間的討論，

另一方面，gRPC是一個RPC框架，以服務方法為中心，如果以圖書 API為例，使用gRPC，將使用以下方法創建 BookService ：

• GetBooks()
• GetBook()
• CreateBook()
• DeleteBook()

可以隨心所欲地命名這些方法，并設定任何需要的引數，如果現在想添加一個方法來創建多本書，沒有什么能阻止我們添加 CreateBooks() 方法，gRPC 在設計 API 時提供了更多的“自由”，因為有更少的（自我強加的）限制，

服務模式

gRPC 支持四種服務方法：

• 一元流：發送單個請求，接收單個回應，
• 服務器流：發送單一請求，接收多個回應，
• 客戶端流：發送多個請求，接收單一回應，
• 雙向流：發送多個請求，接收多個回應，

與只支持一元請求的 REST 相比，gRPC 有一個非常好的優勢，在 REST API 中支持其他服務模式需要使用不同的協議，例如：服務器發送的事件或websocket，這不是很“RESTful”，

要求

REST API通常“只適用于”任何型別的 HTTP 版本，只要一種編程語言有一個 HTTP 客戶端和一個用于 JSON 決議的庫，那么使用 REST API 就輕而易舉了，

gRPC 明確需要 HTTP/2 支持，否則它將無法作業，近年來，由于大多數框架都增加了對 HTTP/2 的支持，這已經不再是一個問題了，

由于 gRPC 需要生成代碼（用于創建客戶端或服務器存根），因此區域分編程語言支持，查看編程語言串列，

API 設計

REST API 通常是其實作的結果，稱為“代碼優先（code-first）”，雖然可以先用 OpenAPI 設計API，然后生成服務器存根，但這不是許多開發人員采用的方法，如果有一個 OpenAPI 定義，那么 OpenAPI 定義很可能是從 API 實作生成的，因此，API定義與實作緊密耦合，模型類的更改可能會導致 API 更改，無意中破壞介面規范，

gRPC 使用不同的方法，在實作API之前必須定義API（稱為“設計優先（design-first）”），然后根據 API 定義生成客戶端和服務器存根，這需要提前考慮，因為不能直接實作API，

兩種方法各有利弊，通常 REST API 方法允許快速迭代；使用gRPC，在調整 API 實作之前首先更改 API 定義，這可能會很煩人，然而，通過顯式定義API更加安全，API變動沒那么隨意，

資料格式

REST 和 gRPC 都可以使用不同的格式來傳輸資料，大多數 REST API 使用JSON，而 gRPC 默認使用 Protocol Buffers，一種輕便高效的結構化資料存盤格式，因此我們將比較這兩者，

JSON 對資料型別的支持有限，例如，大數字需要表示為字串，JOSON 是一種文本格式，便于閱讀，欄位名序列化會占用一些空間，在一些編程語言中，還需要使用反射來反序列化 JSON 訊息，速度慢，

如上所述，gRPC API 和相應的訊息型別首先被定義為 Protocol Buffers ，每條訊息都是強型別的，對于支持的編程語言，可以自動生成代碼以（反）序列化訊息，由于它是一種二進制格式，并且不序列化欄位名，因此它使用的空間比等效的JSON訊息少，但是存在缺點：即序列化訊息不可讀，并且需要 Protobuf 定義來反序列化訊息，可能會影響開發人員的體驗，

下面的 JSON 示例將占用大約66個位元組（去掉空白），

{
  "persons": [
    {
      "name": "Max",
      "age": 23
    },
    {
      "name": "Mike",
      "age": 52
    }
  ]
}

等效的序列化 protobuf 訊息將僅使用19個位元組，

0x0A070A034D617810170A080A0448616E731034

大訊息

Protobuf 設計用于序列化和反序列化記憶體中的訊息，因此，不建議使用 Protobuf/gRPC 傳輸巨大的訊息，大多數 gRPC 實作對單個訊息的默認限制為4MB，

使用 REST API 處理大資料量（例如檔案上傳）是相當直接的，接收到的檔案可以被視為流，只需使用很少的記憶體，這在 gRPC 中需要更多的操作：檔案必須在發送方分為幾個部分，然后，每個塊將作為單獨的訊息通過客戶端流傳輸方法發送到服務器，服務器接收每個塊，并構造資料流，從而產生與 REST API 類似的行為，

瀏覽器兼容性

瀏覽器兼容是 REST 真正的閃光點，它由 WEB 瀏覽器本地支持，因此可以輕松地使用 WEB應用程式中的 REST API，

gRPC 不直接由瀏覽器支持，因為它需要明確的 HTTP/2 支持和訪問某些 HTTP/2 功能，而 WEB瀏覽器不提供這些功能，作為一種變通方法，可以使用 gRPC Web 協議，使其可供 WEB 瀏覽器使用，對于某些編程語言，框架中已經包含了gRPC Web 支持，對于其他場景，需要一個代理來將 gRPC 流轉換為 gRPC Web 流，反之亦然，與不需要依賴關系的 REST API 相比，gRPC API 在 WEB 上使用更麻煩，

解決方法可以是使用 JSON 轉碼，這允許開發人員將 gRPC API 公開為 REST API，

工具

gRPC 和 REST 工具在編程語言和框架之間差異很大，在某些情況下，gRPC 感覺更“原生”，而在另一些情況下，REST 工具則更高級，
對 gRPC 的編程語言支持更為重要，因為需要工具來生成特定編程語言的客戶端和服務器存根，對于不受支持的編程語言，不建議使用 gRPC ，

由于 REST API 存在的時間要長得多，因此存在更多有助于構建、測驗和部署 REST API 的工具，它們的功能通常比 gRPC 工具更高級，

小結

對于“應該使用 REST 還是 gRPC ？” 沒有明確的答案，有些 API 有獨特的用例，gRPC 或 REST 可能更適合這些用例，

REST 和 gRPC 都有各自的優點和缺點，

從 WEB 應用程式中使用 REST API 通常更容易，REST也得到了更廣泛的使用，這使得開發人員使用它更簡單，

gRPC 在服務器到服務器的通信（例如：微服務之間）方面無疑具有優勢，能夠共享準確的API定義并用多種編程語言創建 API 客戶端，這是一個巨大的優勢，

dotNET兄弟會-公眾號

專注.Net開源技術及跨平臺開發！致力于構建完善的.Net開發技術文庫！為.Net愛好者提供學習交流家園！

標籤：其他

上一篇：翻譯：REST 和 gRPC 詳細比較

下一篇：返回列表