技術選型：如何選擇REST、GraphQL 和 gRPC

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、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可能過於複雜，增加了不必要的開銷。
• 不支援網頁瀏覽器：由於gRPC使用HTTP/2協議，而網頁瀏覽器目前還不支援HTTP/2協定的所有功能，因此不能在網頁瀏覽器中使用gRPC。

何時選擇gRPC

1. 需要高效能的資料傳輸：由於gRPC使用二進位協議，因此比JSON和XML等文字協定更快、更輕量級。
2. 需要高可靠性：gRPC的基於HTTP/2協定的傳輸層提供了許多功能，例如流控制、連接復用和頭部壓縮等，這些功能可以提高可靠性和性能。
3. 需要高效率的多語言通訊：gRPC支援多種程式語言，並提供了自動產生程式碼的工具，因此不需要手動編寫跨語言的程式碼。
4. 需要支援多種請求和回應類型：gRPC支援四種類型的通訊方式（Unary、Server streaming、Client streaming和Bidirectional streaming），因此可以選擇最適合特定用例的通信方式。
5. 需要更好的API管理：gRPC提供了強大的API管理工具，例如gRPC-Gateway和Envoy等，這些工具可以提高API的可發現性、文件化和測試。

gRPC 可以用在微服務架構中來處理服務之間的通信，因為它可以與用不同語言編寫的服務進行通訊。

結論

選擇REST、GraphQL和gRPC取決於你的具體場景和需求，基本原則總結如下：

1. REST：REST適合簡單的API和Web服務，例如傳統的CRUD操作。它通常更易於理解和使用，並且具有廣泛的支援和工俱生態系統。
2. GraphQL：GraphQL適合需要靈活性和進階查詢功能的應用程式。如果你的應用程式需要從多個資源聚合數據，或者需要更好地控制數據的格式和粒度，則GraphQL是一個不錯的選擇。
3. gRPC：gRPC適合需要高效可靠資料傳輸的應用程式。如果你需要在多種程式語言之間進行高效通信，並且希望提供更高的性能和可靠性，則gRPC是一個不錯的選擇。

不過，REST、GraphQL和gRPC並不是互相排斥的選擇。在實際情況下，你可以結合使用，以滿足具體需求和場景。

#

以上是技術選型：如何選擇REST、GraphQL 和 gRPC的詳細內容。更多資訊請關注PHP中文網其他相關文章！