REST、GraphQL和gRPC是現(xiàn)代網(wǎng)絡(luò)應(yīng)用中最流行的三種API開發(fā)技術(shù)。然而，選擇一種并不容易，因?yàn)樗鼈兌加歇?dú)特的功能。

在這篇文章中，我將比較和對(duì)比REST、GraphQL和gRPC的特點(diǎn)和用途，以幫助你決定你的項(xiàng)目的最佳選擇。

REST - 最受歡迎的技術(shù)

代表性狀態(tài)傳輸（REST）是現(xiàn)代網(wǎng)絡(luò)開發(fā)中最流行的API開發(fā)技術(shù)。它為數(shù)據(jù)傳輸提供了一個(gè)無狀態(tài)的架構(gòu)?？蛻舳苏?qǐng)求包含所有需要的細(xì)節(jié)來完成請(qǐng)求，而服務(wù)器不保留客戶端的狀態(tài)。

REST APIs支持本地HTTP緩存頭，并使用HTTP方法（POST、GET、PUT、PATCH和DELETE）來操作數(shù)據(jù)。任何人都可以很容易地開始使用REST，因?yàn)樗芎?jiǎn)單，學(xué)習(xí)曲線很淺。

此外，REST很容易擴(kuò)展和可靠。因此，開發(fā)人員可以毫無疑義地選擇它作為他們的應(yīng)用程序。甚至像Twitter、Paypal和Google這樣的公司也在其產(chǎn)品中使用REST APIs。

REST的好處

你可以放心地使用標(biāo)準(zhǔn)的HTTP方法實(shí)現(xiàn)CRUD操作。

REST已經(jīng)存在了很長(zhǎng)時(shí)間，幾乎每個(gè)開發(fā)者都知道如何使用它。

它支持緩存。

它是可擴(kuò)展的，并提供客戶端和服務(wù)器之間的分離。

你可以輕松地將它集成到多個(gè)應(yīng)用程序中。

REST的缺點(diǎn)

它有過度獲取和不足獲取的問題。

它不能維護(hù)狀態(tài)。

它有很大的有效載荷大小。

端點(diǎn)的數(shù)量隨著應(yīng)用程序的擴(kuò)展而急劇增加。

更新數(shù)據(jù)庫模式或數(shù)據(jù)結(jié)構(gòu)并不容易。

何時(shí)選擇REST

如果你沒有任何特殊要求，REST是最好的選擇。例如，如果你是開發(fā)新手，使用REST是完美的選擇，因?yàn)樗膶W(xué)習(xí)曲線很淺。此外，它有一個(gè)龐大的生態(tài)系統(tǒng)，你可以很容易地找到你面臨的任何問題的解決方案。

另外，在處理許多請(qǐng)求和有限的帶寬時(shí)，你最好使用REST。你可以使用它的緩存支持來提高這種情況下的性能。

總的來說，我們不能把REST的使用限制在某些類型的應(yīng)用程序中。例如，如果你的應(yīng)用程序明確要求GraphQL或gRPC，你可以使用REST。

GraphQL--一個(gè)客戶端驅(qū)動(dòng)的標(biāo)準(zhǔn)

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

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

查詢 - 從服務(wù)器上請(qǐng)求數(shù)據(jù)。

突變 - 修改服務(wù)器端的數(shù)據(jù)。

訂閱 - 在數(shù)據(jù)更新時(shí)獲得實(shí)時(shí)更新。

GitHub是使用GraphQL的最大公司之一。它在2016年從REST切換到GraphQL，這極大地幫助了GitHub的快速增長(zhǎng)。

GraphQL的好處

它是高度靈活的，并能精確地提供客戶所需的東西。

它沒有過度獲取和不足獲取的問題。

它受到知名語言的支持，包括JavaScript、Java、Python、Ruby和PHP。

它允許定制數(shù)據(jù)的結(jié)構(gòu)。

一個(gè)單一的查詢可以包含來自多個(gè)資源的字段。

GraphQL的缺點(diǎn)

查詢可能很復(fù)雜。

它缺乏內(nèi)置的緩存支持。

與REST相比，學(xué)習(xí)GraphQL可能是一個(gè)挑戰(zhàn)。

默認(rèn)情況下，它不支持文件上傳。

何時(shí)選擇GraphQL

GraphQL是查詢有許多記錄的數(shù)據(jù)庫的最佳選擇。你可以用GraphQL消除過度獲取，只檢索特定格式的必要數(shù)據(jù)，以提高應(yīng)用性能。另外，GraphQL很適合你需要從多個(gè)資源匯總數(shù)據(jù)的情況。

當(dāng)你不完全了解客戶端如何使用API時(shí)，你也可以使用GraphQL。使用GraphQL，你不需要在前期定義一個(gè)嚴(yán)格的合同。相反，你可以根據(jù)客戶的反饋逐漸建立起API。

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

gRPC是谷歌在2016年推出的遠(yuǎn)程程序調(diào)用的進(jìn)化版。它是一個(gè)輕量級(jí)的解決方案，使用最小的資源提供最大的性能。

gRPC遵循一種基于合同的通信方法。gRPC使用Protobuf（一種聲明性語言）來創(chuàng)建合同，并使用選定的語言為客戶端和服務(wù)器生成兼容代碼。

gRPC支持4種通信方法：

1. 單一的 - 首先，客戶向服務(wù)器提出一個(gè)單一的請(qǐng)求。然后，服務(wù)器發(fā)送一個(gè)單一的響應(yīng)。

2. 客戶端流式 - 首先，客戶端向服務(wù)器流式傳輸一系列請(qǐng)求，然后用一條消息通知流式傳輸結(jié)束。最后，服務(wù)器發(fā)送一個(gè)單一的回復(fù)。

3. 服務(wù)器流 - 首先，客戶端向服務(wù)器提出一個(gè)單一的請(qǐng)求。然后，服務(wù)器向客戶端發(fā)送一個(gè)消息流。

4. 雙向流 - 客戶端和服務(wù)器都可以在建立初始連接后的任何時(shí)間發(fā)送消息。

gRPC的好處

它是開源的。所以開發(fā)者可以根據(jù)需要修改它。

它支持多種語言，包括JavaScript、Java、C、C++、C#、Kotlin、Python、Go和PHP。

它能夠進(jìn)行負(fù)載平衡。

它默認(rèn)使用HTTP2，以減少與REST APIs相比的延遲。

它以二進(jìn)制格式序列化數(shù)據(jù)。

它支持全雙工流。

gRPC的缺點(diǎn)

它默認(rèn)不支持瀏覽器。

與REST和GraphQL相比，它沒有堅(jiān)實(shí)的社區(qū)支持。

何時(shí)選擇gRPC

gRPC是低資源設(shè)備間通信的一個(gè)很好的選擇。例如，物聯(lián)網(wǎng)設(shè)備、智能設(shè)備和相機(jī)可以從使用gRPC中受益，因?yàn)樗梢岳米钚〉馁Y源優(yōu)化性能。

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

總結(jié)

我在這篇文章中討論了3種最流行的API開發(fā)技術(shù)，它們的優(yōu)點(diǎn)、缺點(diǎn)，以及我們應(yīng)該何時(shí)選擇它們。我希望你現(xiàn)在已經(jīng)更好地理解了REST、GraphQL和gRPC，以便為你的應(yīng)用選擇最好的一種。

然而，重要的是要注意，我們不能把一個(gè)放在另一個(gè)上面，說這個(gè)比另一個(gè)優(yōu)越。每一種都有獨(dú)特的功能，你應(yīng)該根據(jù)你的項(xiàng)目要求來選擇一個(gè)。

我希望你認(rèn)為這篇文章對(duì)你有幫助。謝謝您的閱讀!