>譯者註：在微服務架構設計，構建API和服務間通信技術選型時，對 REST 和 gRPC 的理解和應用還存在知識盲區，近期看到國外的這篇文章：[A detailed comparison of REST and gRPC](https://kreya.app/blog/rest-vs-grpc/)， ...
譯者註：在微服務架構設計，構建API和服務間通信技術選型時，對 REST 和 gRPC 的理解和應用還存在知識盲區，近期看到國外的這篇文章：A detailed comparison of REST and gRPC，將二者進行了詳細對比。周末有時間翻譯過來，希望能幫到大家！
很長一段時間以來，REST是構建API的唯一“標準”。近年來，出現了新的替代方案。2015年，臉書發佈了GraphQL，2016年谷歌緊隨其後發佈了gRPC，被廣泛使用。在本文中，將關註gRPC，並將其與REST進行比較。
概述
下表將概述本文討論的要點，並顯示 REST 和 gRPC 真正的亮點。
| 主題 | REST | gRPC |
|---|---|---|
| 標準化 | 無標準 | 定義明確 |
| 範式 | 以資源為中心 | 以服務方法為中心 |
| 服務模式 | 一元流 | 一元流、客戶端流、伺服器流和雙向流 |
| 要求 | 任何 HTTP、Json解析 | 編程語言需要支持 HTTP/2, gRPC |
| API 設計 | 代碼優先 | 設計優先 |
| 預設數據格式 | Json | Protobuf |
| WEB瀏覽器支持 | 瀏覽器本地支持 | gRPC WEB |
| 工具 | 成熟的工具 | 特定編程語言工具 |
標準化
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愛好者提供學習交流家園！
