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

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

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

REST

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

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

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

REST的好處

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

REST的缺點(diǎn)

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

何時(shí)選擇 REST

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

在處理較大的請求量和帶寬有限時(shí)最好使用 REST，因?yàn)榭梢允褂盟木彺嬷С謥硖岣咝阅堋?/span>

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

GraphQL——客戶端驅(qū)動的標(biāo)準(zhǔn)

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

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

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

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

GraphQL 的好處

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

GraphQL 的缺點(diǎn)

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

何時(shí)選擇 GraphQL

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

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

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

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

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

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

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

gRPC 的好處

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

gRPC 的缺點(diǎn)

• 學(xué)習(xí)曲線較陡峭：與傳統(tǒng)的REST API相比，gRPC需要掌握新的概念和技術(shù)，例如Protocol Buffers和流。
• 可讀性差：由于使用二進(jìn)制編碼，gRPC的消息不像JSON或XML那樣易于人類閱讀和理解。
• 難以調(diào)試：由于消息是二進(jìn)制編碼的，調(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。

何時(shí)選擇 gRPC

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

gRPC 可以用在微服務(wù)架構(gòu)中來處理服務(wù)之間的通信，因?yàn)樗梢耘c用不同語言編寫的服務(wù)進(jìn)行通信。

結(jié)論

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

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

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