1. 概述

在本文中，我們將比較 REST 和 gRPC，這兩種用於 Web API 的架構風格。

2. 什麼是 REST？

REST (Representational State Transfer) 是一種架構風格，為設計 Web API 提供指導原則。

它使用標準 HTTP 1.1 方法，如 GET、POST、PUT 和 DELETE 來與服務器端資源交互. 此外，REST API 提供預定義的 URL，客户端必須使用這些 URL 與服務器連接。

3. 什麼是 gRPC？

gRPC (遠程過程調用) 是一種由 Google 開發的開源數據交換技術，使用 HTTP/2 協議。

它使用 Protocol Buffers 二進制格式 (Protobuf) 進行數據交換。 此外，這種架構風格強制開發者遵循規則，以便開發或消費 Web API。

4. REST 與 gRPC

4.1. 指南與規則

REST 是一套為設計 Web API 提供指南的集合，它不強制執行任何內容。相反，gRPC 通過定義一個.proto 文件來強制執行規則，客户端和服務器必須遵守該文件以進行數據交換。

4.2. 基礎 HTTP 協議

REST 提供基於 HTTP 1.1 協議的請求-響應通信模型。因此，當多個請求到達服務器時，它必須逐個處理它們。

然而，gRPC 遵循客户端-響應的通信模型，用於設計基於 HTTP/2 的 Web API。因此，gRPC 允許流式通信並同時處理多個請求。此外，gRPC 還支持與 REST 類似的單向通信。

4.3. 數據交換格式

REST 通常使用 JSON 和 XML 格式進行數據傳輸。然而，gRPC 依賴 Protobuf 用於在 HTTP/2 協議上傳輸數據。

4.4. 序列化與強類型

REST 在大多數情況下使用 JSON 或 XML，這需要序列化和轉換成目標編程語言，以便客户端和服務器進行解析，從而增加了響應時間以及解析請求/響應的可能性。

然而，gRPC 提供通過 Protobuf 交換格式自動轉換成所選編程語言的強類型消息。

4.5. 延遲

REST 利用 HTTP 1.1 需要每個請求進行 TCP 手shake。因此，使用 HTTP 1.1 的 REST API 可能會出現延遲問題。

另一方面，gRPC 依賴 HTTP/2 協議，該協議使用多路複用流。因此，多個客户端可以同時發送多個請求，而無需為每個請求建立新的 TCP 連接。此外，服務器可以通過已建立的連接向客户端發送推送通知。

4.6. 瀏覽器支持

使用 HTTP 1.1 的 REST API 具有普遍的瀏覽器支持。

然而，gRPC 具有有限的瀏覽器支持，因為許多瀏覽器（通常是較舊的版本）沒有成熟的 HTTP/2 支持。因此，可能需要 gRPC-web 和代理層來在 HTTP 1.1 和 HTTP/2 之間進行轉換。因此，目前 gRPC 主要用於內部服務。

4.7. 代碼生成功能

REST 不提供內置的代碼生成功能。但是，我們可以使用 Swagger 或 Postman 等第三方工具來生成 API 請求的代碼。

另一方面，gRPC，使用其protoc 編譯器，具有原生代碼生成功能，與多種編程語言兼容。

5. 結論

在本文中，我們比較了 REST 和 gRPC 兩種 API 架構風格。

我們得出結論，REST 在集成微服務和核心繫統與第三方應用程序方面非常實用。

然而，gRPC 可以應用於諸如 物聯網系統（需要輕量級消息傳輸）、不支持瀏覽器的移動應用程序以及需要多路複用流的應用程序等系統。