REST 與 gRPC：API 之戰
REST API 長期以來一直是 Web 編程的支柱。但最近 gRPC 開始蠶食其領土。
Protobuf 與 JSON
REST 和 gRPC 之間最大的區別之一是負載的格式。REST 消息通常包含 JSON。這不是一個嚴格的要求，理論上您可以發送任何內容作為響應，但實際上整個 REST 生態系統（包括工具、最佳實踐和教程）都專注於 JSON。可以肯定地說，除了極少數例外，REST API 接受並返回 JSON。
另一方面，gRPC 接受並返回Protobuf消息。稍后我將討論強類型，但僅從性能的角度來看，Protobuf 是一種非常高效且緊湊的格式。另一方面，JSON 是一種文本格式。您可以壓縮 JSON，但隨后就失去了您可以輕松期望的文本格式的好處。
HTTP/2 與 HTTP 1.1
讓我們比較一下 REST 和 gRPC 使用的傳輸協議。如前所述，REST 在很大程度上依賴於 HTTP（通常是 HTTP 1.1）和請求-響應模型。另一方面，gRPC 使用較新的 HTTP/2 協議。
HTTP/2 修復了幾個困擾 HTTP 1.1 的問題。
HTTP/2 源自 Google 的 SPDY。HTTP/2 協議是二進制的！
大多數實現並沒有完全遵循 REST 哲學並且只使用其原則的一個子集。原因是將業務邏輯和操作映射到嚴格的 REST 世界實際上非常具有挑戰性。
gRPC 使用的概念模型是為請求和響應提供具有清晰接口和結構化消息的服務。該模型直接從編程語言概念（如接口、函數、方法和數據結構）轉換而來。它還允許 gRPC 為您自動生成客戶端庫。
REST 僅支持 HTTP 1.x 中可用的請求-響應模型。但是 gRPC 充分利用了 HTTP/2 的功能，讓您不斷地流式傳輸信息。
REST 范式不強制要求交換有效負載的任何結構。它通常是 JSON。消費者沒有正式的機制來協調請求和響應的格式。必須在服務器端和客戶端將 JSON 序列化並轉換為目標編程語言。序列化是鏈中的另一個步驟，它引入了錯誤的可能性以及性能開銷。
gRPC 服務合約具有強類型消息，這些消息會自動從其 Protobuf 表示轉換為您在服務器和客戶端上選擇的編程語言。
SON 理論上更靈活，因為您可以發送動態數據，而不必遵守嚴格的結構。
瀏覽器中對 gRPC 的支持還不夠成熟。今天，gRPC 主要用於不直接向外界公開的內部服務。
在微服務領域，gRPC 很快就會占據主導地位。性能優勢和易於開發的優勢不容錯過。但是，請不要誤會，REST 仍然會存在很長時間。由於公開的 API 和向后兼容的原因，它仍然表現出色。