1. 概述
本文將比較 REST 和 gRPC，這兩種用於 Web API 的架構風格。
2. REST 架構是什麼？
REST (表徵性狀態轉移) 是一種架構風格，為設計 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 vs. gRPC
REST (Representational State Transfer) 和 gRPC 都是用於構建分佈式系統的通信協議。雖然兩者都旨在實現服務之間的交互，但它們在設計理念、性能和適用場景上存在顯著差異。
REST
REST 是一種基於 HTTP 協議的架構風格，它依賴於標準 HTTP 方法（GET, POST, PUT, DELETE）來操作資源。RESTful 服務通常使用 JSON 或 XML 格式的數據進行傳輸。
- 優點:
- 易於理解和使用: REST 的設計理念簡單易懂，易於學習和使用。
- 廣泛的工具和庫支持: REST 擁有龐大的生態系統，提供了大量的工具和庫支持。
- 跨平台兼容性: REST 協議在各種平台和語言中都有良好的支持。
- 缺點:
- 性能較低: 由於 REST 協議的開銷較大，在數據傳輸和處理方面可能不如 gRPC 效率高。
- 序列化/反序列化開銷: JSON 或 XML 格式的序列化和反序列化過程會帶來額外的開銷。
gRPC
gRPC (gRPC Remote Procedure Calls) 是一種高性能、開源的 RPC 框架，由 Google 開發。它基於 Protocol Buffers 序列化格式，並使用 HTTP/2 作為傳輸協議。
- 優點:
- 高性能: gRPC 使用 Protocol Buffers 序列化格式，以及 HTTP/2 協議，可以顯著提高數據傳輸和處理的效率。
- 流式傳輸: gRPC 支持雙向流式傳輸，可以實現實時通信。
- 類型安全: Protocol Buffers 提供了類型安全，可以減少運行時錯誤。
- 缺點:
- 學習曲線較陡峭: gRPC 的配置和使用相對複雜，需要學習 Protocol Buffers 及其相關工具。
- 生態系統相對較小: 相比於 REST，gRPC 的生態系統相對較小，工具和庫支持可能不夠完善。
總結
| 特性 | REST | gRPC |
|---|---|---|
| 協議 | HTTP/1.1 | HTTP/2 |
| 序列化格式 | JSON, XML | Protocol Buffers |
| 性能 | 較低 | 較高 |
| 適用場景 | Web 應用, API | 高性能服務, 微服務 |
選擇 REST 還是 gRPC 取決於具體的應用場景和需求。如果需要構建 Web 應用或 API，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. 延遲 (Latency)
REST 使用 HTTP 1.1 需要為每個請求進行 TCP 手動握握，因此，使用 HTTP 1.1 的 REST API 可能會出現延遲問題。
另一方面，gRPC 依賴於 HTTP/2 協議，該協議使用多路複用流。因此，多個客户端可以同時發送多個請求，而無需為每個請求建立新的 TCP 連接。此外，服務器可以通過已建立的連接向客户端發送推播通知。
4.6. 瀏覽器支持
REST APIs 在 HTTP 1.1 上具有普遍的瀏覽器支持。
然而，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 可以應用於諸如 物聯網系統（需要輕量級消息傳輸）、不支持瀏覽器應用程序的移動應用程序以及需要多路複用流的應用程序等系統。
