REST、GraphQL 和 gRPC 是現代 Web 應用程序中最流行的 3 種 API 開發技術。那么在做技術選型時，三者要如何選擇呢？
在本文中，我們將一起對比 REST、GraphQL 和 gRPC 的特性和用法。
REST——最流行的技術
REST
Representational State Transfer (REST) 是現代 Web 開發中最流行的 API 開發技術。它是一個無狀態的數據傳輸架構。客戶端請求時會包含該請求所需的所有詳細信息，但是服務器不保留客戶端的狀態。
REST API 支持 HTTP 原生緩存 header 并使用 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）來操作數據。因為 REST 的學習門檻較低，所以大家都能輕松使用 REST。
REST 易于擴展且可靠，如果我們還在猶豫不決時，可以優先選擇它。
REST的好處
- 可以放心地使用標準 HTTP 方法實現 CRUD 操作。
- REST 已經很成熟，有完善的文檔，上手簡單。
- 支持緩存。
- 友好的可擴展性，并提供客戶端和服務器之間的分離。
- 可以輕松地將其集成到應用程序中。
REST的缺點
- 存在過度獲取和獲取不足的問題。當API返回比實際需要的數據更多時，就會發生過度獲取。這可能會導致不必要的網絡流量、較慢的性能和額外的帶寬使用。獲取不足發生在API沒有返回特定用例所需的所有必要數據時，需要多個請求才能檢索所有所需信息。這也可能導致較慢的性能和增加的網絡流量，以及更復雜的代碼庫。
- 不能維持狀態。
- 相對來說比較大的 payload。
- 隨著應用程序的擴展，端點的數量急劇增加。
- 不容易更新數據庫模式或數據結構。
何時選擇 REST
如果沒有特定要求，REST 是最佳選擇。如果是開發新手，那么使用 REST 是完美的選擇，因為它的學習曲線較淺。此外，它還擁有龐大的生態系統，你可以輕松找到問題的解決方案。
在處理較大的請求量和帶寬有限時最好使用 REST，因為可以使用它的緩存支持來提高性能。
總的來說，如果你的應用程序沒有明確需要使用 GraphQL 或 gRPC，那么就可以使用 REST。
GraphQL——客戶端驅動的標準
GraphQL 是 2015 年推出的一種數據查詢語言，支持開發人員精確定位和獲取他們需要的數據。與 REST 相比，GraphQL 是一種客戶端驅動的方法，客戶端可以決定需要什么數據、如何獲取數據和格式。它還解決了過度獲取和獲取不足的問題，因為客戶端可以明確指定所需的數據。
GraphQL 使用查詢、變更和訂閱來操作數據。
- 查詢：從服務器請求數據。
- 變更：修改服務器端數據。
- 訂閱：在數據更新時，通過訂閱獲得實時更新的數據。
GitHub 是使用 GraphQL 的最大公司之一。它在 2016 年從 REST 轉向 GraphQL，極大地幫助了 GitHub 的快速增長。
GraphQL 的好處
- 非常靈活，可以準確地滿足客戶的需求。
- 沒有過度獲取和獲取不足的問題。
- 主流語言支持，包括 JAVAScript、Java、Python/ target=_blank class=infotextkey>Python、Ruby 和 php。
- 允許自定義數據的結構。
- 單個查詢可以包含來自多個資源的字段。
GraphQL 的缺點
- 查詢可能很復雜。
- 缺乏內置的緩存支持。
- 與 REST 相比，學習 GraphQL 更具挑戰性。
- 默認不支持文件上傳。
何時選擇 GraphQL
當查詢包含數據庫的許多記錄時，GraphQL 是最佳選擇。你可以使用 GraphQL 消除過度獲取，并僅查詢必要數據以提高應用程序性能。此外，GraphQL 非常適合需要從多個資源聚合數據的情況。
當你還不完全了解客戶端使用 API 的原理時，也可以使用 GraphQL。使用 GraphQL 時，你無需預先定義嚴格的協議，可以根據客戶反饋逐步構建 API。
gRPC——一種以性能為導向的技術
gRPC 是 google 于 2016 年推出的遠程過程調用的進化版本。它是一種輕量級解決方案，使用最少的資源提供最大的性能。
gRPC 遵循基于協議的通信方法。它要求客戶端和服務器在開始通信之前都有協議。gRPC 使用 Protobuf（一種聲明性語言）創建協議，并使用選定的語言為客戶端和服務器生成兼容的代碼。
gRPC支持的通信方式有4種：
- Unary ：客戶端發送一個請求并等待單個響應。
- Server streaming ：客戶端發送一個請求并接收多個響應。
- Client streaming ：客戶端發送多個請求并等待單個響應。
- Bidirectional streaming ：客戶端發送多個請求并接收多個響應。
gRPC 的好處
- 開源。開發人員可以根據需要對其進行修改。
- 支持多種語言，包括 JavaScript、Java、C、C++、C#、Kotlin、Python、Go 和 PHP。
- 能夠進行負載均衡。
- 與 REST API 相比，它默認使用 HTTP2 來減少延遲。
- 使用二進制格式序列化數據。
- 支持全雙工流媒體。
gRPC 的缺點
- 學習曲線較陡峭：與傳統的REST API相比，gRPC需要掌握新的概念和技術，例如Protocol Buffers和流。
- 可讀性差：由于使用二進制編碼，gRPC的消息不像JSON或XML那樣易于人類閱讀和理解。
- 難以調試：由于消息是二進制編碼的，調試gRPC服務可能比調試REST API更加困難。
- 不適合小型應用：對于只有少量服務和少量數據的小型應用程序來說，gRPC可能過于復雜，增加了不必要的開銷。
- 不支持Web瀏覽器：由于gRPC使用HTTP/2協議，而Web瀏覽器目前還不支持HTTP/2協議的所有功能，因此不能在Web瀏覽器中使用gRPC。
何時選擇 gRPC
- 需要高效的數據傳輸：由于gRPC使用二進制協議，因此比JSON和XML等文本協議更快、更輕量級。
- 需要高可靠性：gRPC的基于HTTP/2協議的傳輸層提供了許多功能，例如流控制、連接復用和頭部壓縮等，這些功能可以提高可靠性和性能。
- 需要高效的多語言通信：gRPC支持多種編程語言，并提供了自動生成代碼的工具，因此不需要手動編寫跨語言的代碼。
- 需要支持多種請求和響應類型：gRPC支持四種類型的通信方式（Unary、Server streaming、Client streaming和Bidirectional streaming），因此可以選擇最適合特定用例的通信方式。
- 需要更好的API管理：gRPC提供了強大的API管理工具，例如gRPC-Gateway和Envoy等，這些工具可以提高API的可發現性、文檔化和測試。
gRPC 可以用在微服務架構中來處理服務之間的通信，因為它可以與用不同語言編寫的服務進行通信。
結論
選擇REST、GraphQL和gRPC取決于你的具體場景和需求，基本原則總結如下：
- REST：REST適合簡單的API和Web服務，例如傳統的CRUD操作。它通常更易于理解和使用，并且具有廣泛的支持和工具生態系統。
- GraphQL：GraphQL適合需要靈活性和高級查詢功能的應用程序。如果你的應用程序需要從多個資源聚合數據，或者需要更好地控制數據的格式和粒度，則GraphQL是一個不錯的選擇。
- gRPC：gRPC適合需要高效和可靠數據傳輸的應用程序。如果你需要在多種編程語言之間進行高效通信，并且希望提供更高的性能和可靠性，則gRPC是一個不錯的選擇。
不過，REST、GraphQL和gRPC并不是相互排斥的選擇。在實際情況下，你可以結合使用，以滿足具體需求和場景。
