技術(shù)選型：如何選擇REST、GraphQL 和 gRPC-魔扣目錄

REST、GraphQL 和 gRPC 是現(xiàn)代 Web 應(yīng)用程序中最流行的 3 種 API 開發(fā)技術(shù)。那么在做技術(shù)選型時，三者要如何選擇呢？

在本文中，我們將一起對比 REST、GraphQL 和 gRPC 的特性和用法。

REST——最流行的技術(shù)

REST

Representational State Transfer (REST) 是現(xiàn)代 Web 開發(fā)中最流行的 API 開發(fā)技術(shù)。它是一個無狀態(tài)的數(shù)據(jù)傳輸架構(gòu)。客戶端請求時會包含該請求所需的所有詳細信息，但是服務(wù)器不保留客戶端的狀態(tài)。

REST API 支持 HTTP 原生緩存 header 并使用 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）來操作數(shù)據(jù)。因為 REST 的學(xué)習(xí)門檻較低，所以大家都能輕松使用 REST。

REST 易于擴展且可靠，如果我們還在猶豫不決時，可以優(yōu)先選擇它。

REST的好處

可以放心地使用標準 HTTP 方法實現(xiàn) CRUD 操作。
REST 已經(jīng)很成熟，有完善的文檔，上手簡單。
支持緩存。
友好的可擴展性，并提供客戶端和服務(wù)器之間的分離。
可以輕松地將其集成到應(yīng)用程序中。

REST的缺點

存在過度獲取和獲取不足的問題。當API返回比實際需要的數(shù)據(jù)更多時，就會發(fā)生過度獲取。這可能會導(dǎo)致不必要的網(wǎng)絡(luò)流量、較慢的性能和額外的帶寬使用。獲取不足發(fā)生在API沒有返回特定用例所需的所有必要數(shù)據(jù)時，需要多個請求才能檢索所有所需信息。這也可能導(dǎo)致較慢的性能和增加的網(wǎng)絡(luò)流量，以及更復(fù)雜的代碼庫。
不能維持狀態(tài)。
相對來說比較大的 payload。
隨著應(yīng)用程序的擴展，端點的數(shù)量急劇增加。
不容易更新數(shù)據(jù)庫模式或數(shù)據(jù)結(jié)構(gòu)。

何時選擇 REST

如果沒有特定要求，REST 是最佳選擇。如果是開發(fā)新手，那么使用 REST 是完美的選擇，因為它的學(xué)習(xí)曲線較淺。此外，它還擁有龐大的生態(tài)系統(tǒng)，你可以輕松找到問題的解決方案。

在處理較大的請求量和帶寬有限時最好使用 REST，因為可以使用它的緩存支持來提高性能。

總的來說，如果你的應(yīng)用程序沒有明確需要使用 GraphQL 或 gRPC，那么就可以使用 REST。

GraphQL——客戶端驅(qū)動的標準

GraphQL 是 2015 年推出的一種數(shù)據(jù)查詢語言，支持開發(fā)人員精確定位和獲取他們需要的數(shù)據(jù)。與 REST 相比，GraphQL 是一種客戶端驅(qū)動的方法，客戶端可以決定需要什么數(shù)據(jù)、如何獲取數(shù)據(jù)和格式。它還解決了過度獲取和獲取不足的問題，因為客戶端可以明確指定所需的數(shù)據(jù)。

GraphQL 使用查詢、變更和訂閱來操作數(shù)據(jù)。

查詢：從服務(wù)器請求數(shù)據(jù)。
變更：修改服務(wù)器端數(shù)據(jù)。
訂閱：在數(shù)據(jù)更新時，通過訂閱獲得實時更新的數(shù)據(jù)。

GitHub 是使用 GraphQL 的最大公司之一。它在 2016 年從 REST 轉(zhuǎn)向 GraphQL，極大地幫助了 GitHub 的快速增長。

GraphQL 的好處

非常靈活，可以準確地滿足客戶的需求。
沒有過度獲取和獲取不足的問題。
主流語言支持，包括 JAVAScript、Java、Python/ target=_blank class=infotextkey>Python、Ruby 和 php。
允許自定義數(shù)據(jù)的結(jié)構(gòu)。
單個查詢可以包含來自多個資源的字段。

GraphQL 的缺點

查詢可能很復(fù)雜。
缺乏內(nèi)置的緩存支持。
與 REST 相比，學(xué)習(xí) GraphQL 更具挑戰(zhàn)性。
默認不支持文件上傳。

何時選擇 GraphQL

當查詢包含數(shù)據(jù)庫的許多記錄時，GraphQL 是最佳選擇。你可以使用 GraphQL 消除過度獲取，并僅查詢必要數(shù)據(jù)以提高應(yīng)用程序性能。此外，GraphQL 非常適合需要從多個資源聚合數(shù)據(jù)的情況。

當你還不完全了解客戶端使用 API 的原理時，也可以使用 GraphQL。使用 GraphQL 時，你無需預(yù)先定義嚴格的協(xié)議，可以根據(jù)客戶反饋逐步構(gòu)建 API。

gRPC——一種以性能為導(dǎo)向的技術(shù)

gRPC 是 google 于 2016 年推出的遠程過程調(diào)用的進化版本。它是一種輕量級解決方案，使用最少的資源提供最大的性能。

gRPC 遵循基于協(xié)議的通信方法。它要求客戶端和服務(wù)器在開始通信之前都有協(xié)議。gRPC 使用 Protobuf（一種聲明性語言）創(chuàng)建協(xié)議，并使用選定的語言為客戶端和服務(wù)器生成兼容的代碼。

gRPC支持的通信方式有4種：

Unary ：客戶端發(fā)送一個請求并等待單個響應(yīng)。
Server streaming ：客戶端發(fā)送一個請求并接收多個響應(yīng)。
Client streaming ：客戶端發(fā)送多個請求并等待單個響應(yīng)。
Bidirectional streaming ：客戶端發(fā)送多個請求并接收多個響應(yīng)。

gRPC 的好處

開源。開發(fā)人員可以根據(jù)需要對其進行修改。
支持多種語言，包括 JavaScript、Java、C、C++、C#、Kotlin、Python、Go 和 PHP。
能夠進行負載均衡。
與 REST API 相比，它默認使用 HTTP2 來減少延遲。
使用二進制格式序列化數(shù)據(jù)。
支持全雙工流媒體。

gRPC 的缺點

學(xué)習(xí)曲線較陡峭：與傳統(tǒng)的REST API相比，gRPC需要掌握新的概念和技術(shù)，例如Protocol Buffers和流。
可讀性差：由于使用二進制編碼，gRPC的消息不像JSON或XML那樣易于人類閱讀和理解。
難以調(diào)試：由于消息是二進制編碼的，調(diào)試gRPC服務(wù)可能比調(diào)試REST API更加困難。
不適合小型應(yīng)用：對于只有少量服務(wù)和少量數(shù)據(jù)的小型應(yīng)用程序來說，gRPC可能過于復(fù)雜，增加了不必要的開銷。
不支持Web瀏覽器：由于gRPC使用HTTP/2協(xié)議，而Web瀏覽器目前還不支持HTTP/2協(xié)議的所有功能，因此不能在Web瀏覽器中使用gRPC。

何時選擇 gRPC

需要高效的數(shù)據(jù)傳輸：由于gRPC使用二進制協(xié)議，因此比JSON和XML等文本協(xié)議更快、更輕量級。
需要高可靠性：gRPC的基于HTTP/2協(xié)議的傳輸層提供了許多功能，例如流控制、連接復(fù)用和頭部壓縮等，這些功能可以提高可靠性和性能。
需要高效的多語言通信：gRPC支持多種編程語言，并提供了自動生成代碼的工具，因此不需要手動編寫跨語言的代碼。
需要支持多種請求和響應(yīng)類型：gRPC支持四種類型的通信方式（Unary、Server streaming、Client streaming和Bidirectional streaming），因此可以選擇最適合特定用例的通信方式。
需要更好的API管理：gRPC提供了強大的API管理工具，例如gRPC-Gateway和Envoy等，這些工具可以提高API的可發(fā)現(xiàn)性、文檔化和測試。

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

結(jié)論

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

REST：REST適合簡單的API和Web服務(wù)，例如傳統(tǒng)的CRUD操作。它通常更易于理解和使用，并且具有廣泛的支持和工具生態(tài)系統(tǒng)。
GraphQL：GraphQL適合需要靈活性和高級查詢功能的應(yīng)用程序。如果你的應(yīng)用程序需要從多個資源聚合數(shù)據(jù)，或者需要更好地控制數(shù)據(jù)的格式和粒度，則GraphQL是一個不錯的選擇。
gRPC：gRPC適合需要高效和可靠數(shù)據(jù)傳輸?shù)膽?yīng)用程序。如果你需要在多種編程語言之間進行高效通信，并且希望提供更高的性能和可靠性，則gRPC是一個不錯的選擇。

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