導(dǎo)讀：在這份學(xué)習(xí)指南中，我們將和大家一起了解 REST、GraphQL 和異步 API 的優(yōu)缺點(diǎn)，以及這三種技術(shù)在現(xiàn)實(shí)生活中的理想用例。

API 在現(xiàn)代軟件開發(fā)領(lǐng)域在發(fā)揮著舉足輕重的作用。

目前，有三種主流類型的API，可用于在各個(gè)系統(tǒng)之間建立通信與數(shù)據(jù)交換。最前沿最流行是 REST 方法，這種方法因其簡單和可擴(kuò)展性，已經(jīng)在行業(yè)中占據(jù)主導(dǎo)地位。

伴隨著技術(shù)的發(fā)展，開發(fā)者與企業(yè)的需求也發(fā)生著變化。近年來，由Facebook開源的 GraphQL 和異步事件驅(qū)動(dòng) API 等替代方案也開始出現(xiàn)。與傳統(tǒng)的 REST API 相比，它們具有更明顯的優(yōu)勢。

在本文中，我們將詳細(xì)研究每種 API 技術(shù)，并將它們做比較和展開理解，希望對(duì)感興趣的小伙伴有些許幫助。

REST：面向資源的通信的開始

REST 架構(gòu)圍繞實(shí)體資源的概念展開。這些實(shí)體可通過標(biāo)準(zhǔn) HTTP 方法進(jìn)行管理，

例如 GET、POST、PUT 和 DELETE。

REST 的關(guān)鍵特征之一就是無狀態(tài)，其中來自客戶端的每個(gè)請(qǐng)求都包含服務(wù)器完成該請(qǐng)求所需的所有信息。

這種方法可以將客戶端和服務(wù)器解耦，彼此可以獨(dú)立擴(kuò)展。

REST 的優(yōu)點(diǎn)與缺點(diǎn)

很明顯，REST API 具有如下的一些優(yōu)勢：

• REST 遵循基于標(biāo)準(zhǔn) HTTP 方法的簡單直觀的設(shè)計(jì)。
• REST 方法中的每個(gè)請(qǐng)求都是獨(dú)立的，從而具有更好的可擴(kuò)展性和可靠性。
• REST 利用 HTTP緩存機(jī)制來增強(qiáng)性能并減少源服務(wù)器上的負(fù)載。
• REST 具有互操作性，由于其標(biāo)準(zhǔn)格式，可以與各種編程語言和平臺(tái)很好地配合。

當(dāng)然，REST架構(gòu)也存在一些缺點(diǎn)：

• REST API 可能會(huì)導(dǎo)致過度獲取，即客戶端收到超出自己所需要的數(shù)據(jù)，從而導(dǎo)致效率低下與帶寬浪費(fèi)。
• 與第一點(diǎn)類似，REST API 也可能獲取不足的問題，即需要增加多個(gè)請(qǐng)求來滿足復(fù)雜的數(shù)據(jù)要求，這樣會(huì)導(dǎo)致延遲增加。
• REST 采用同步方法，在高負(fù)載場景中可能會(huì)導(dǎo)致阻塞與性能問題。
• API數(shù)據(jù)模式的更改會(huì)影響客戶端也要同步，導(dǎo)致緊耦合。

REST API 的用例

REST API 在如下用例中適合，以下我們舉例說明：

• 緩存密集型應(yīng)用程序– 讀取密集型應(yīng)用程序（例如新聞網(wǎng)站或靜態(tài)內(nèi)容）可以從 REST 的緩存機(jī)制中受益。REST 的標(biāo)準(zhǔn)化緩存指令使其更容易實(shí)現(xiàn)。
• 簡單的 CRUD 操作– 在處理簡單的 CRUD 操作時(shí)，REST API 提供簡單性和可預(yù)測性。具有清晰靜態(tài)數(shù)據(jù)模型的應(yīng)用程序通常會(huì)發(fā)現(xiàn) REST API 更合適。

GraphQL：進(jìn)行聲明式數(shù)據(jù)獲取API的興起

GraphQL 是用于查詢數(shù)據(jù)的開源語言以及用于完成這些查詢的運(yùn)行時(shí)的組合。

GraphQL 背后的關(guān)鍵原則是采用分層結(jié)構(gòu)來定義數(shù)據(jù)查詢，讓客戶端在單個(gè)請(qǐng)求中精確指定所需的數(shù)據(jù)。

圖 2?GraphQL 架構(gòu)概覽

在很多方面，GraphQL 都是對(duì) REST API 架構(gòu)相關(guān)問題的直接對(duì)應(yīng)。?

而且它還促進(jìn)了API的強(qiáng)類型模式，為開發(fā)者提供了更清晰的預(yù)期。在技術(shù)改良方法，GraphQL 通過訂閱方式支持實(shí)時(shí)數(shù)據(jù)更新。

經(jīng)過多年的發(fā)展，創(chuàng)始者 Facebook以及眾多生態(tài)公司，比如在 GraphQL Federation 等工具上進(jìn)行了大量工作，從而使 GraphQL API 對(duì)于多個(gè)領(lǐng)域的大型企業(yè)系統(tǒng)具備更良好的可擴(kuò)展性。

GraphQL 的優(yōu)點(diǎn)與缺點(diǎn)

GraphQL 提供給開發(fā)者們?nèi)缦乱恍╆P(guān)鍵優(yōu)勢：

• 使用 GraphQL，客戶端可以僅請(qǐng)求需要的指定數(shù)據(jù)。這一特性消除了REST API 的過度獲取與獲取不足的兩個(gè)問題。
• GraphQL 的強(qiáng)類型模式方法提供了清晰的結(jié)構(gòu)和數(shù)據(jù)驗(yàn)證，從而加快了我們開發(fā)和文檔編寫的速度。
• GraphQL 通常通過單個(gè)節(jié)點(diǎn)進(jìn)行操作。即使數(shù)據(jù)可能有多個(gè)來源，客戶端在與 GraphQL 服務(wù)器通信時(shí)只需要關(guān)心單個(gè)節(jié)點(diǎn)即可。
• 內(nèi)置的自省允許客戶端以探索模式并發(fā)現(xiàn)可用的數(shù)據(jù)和操作。

GraphQL 也有它的缺點(diǎn)，包括如下的幾點(diǎn)：

• 與傳統(tǒng)的 REST API 相比，實(shí)現(xiàn) GraphQL 需要額外的挑戰(zhàn)和專業(yè)知識(shí)。
• 在 GraphQL 中的查詢非常靈活，數(shù)據(jù)的緩存可能具有復(fù)雜性，并且可能需要開發(fā)者實(shí)施自定義解決方案。
• 雖然 GraphQL 減少了頂層的過度獲取，但嵌套查詢?nèi)匀粫?huì)導(dǎo)致不必要的數(shù)據(jù)檢索。
• REST API 的邊界清晰，而目前 GraphQL 層的所有權(quán)問題有時(shí)候會(huì)令人困惑。

GraphQL 的相關(guān)用例

與 REST API 相比，GraphQL 在某些特定場合中表現(xiàn)的更好。例如：

• 復(fù)雜和嵌套的數(shù)據(jù)要求為了要獲取具有復(fù)雜關(guān)系的數(shù)據(jù)，GraphQL 可以讓客戶端在單個(gè)查詢中就可以獲得需要的精確數(shù)據(jù)。
• 實(shí)時(shí)數(shù)據(jù)更新GraphQL 訂閱可幫助應(yīng)用程序處理實(shí)時(shí)數(shù)據(jù)更新，例如聊天應(yīng)用程序或?qū)崟r(shí)儀表盤等。使用 GraphQL，客戶端可以訂閱特定數(shù)據(jù)的更改，無需頻繁輪詢即可實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)更新。
• 微服務(wù)架構(gòu)在微服務(wù)架構(gòu)下，數(shù)據(jù)分布在多個(gè)服務(wù)中。GraphQL 為客戶端提供統(tǒng)一的接口來查詢各種服務(wù)的數(shù)據(jù)。客戶端應(yīng)用程序不必再管理維護(hù)多個(gè) REST 節(jié)點(diǎn)。

異步 API：向事件驅(qū)動(dòng)架構(gòu)的轉(zhuǎn)變

近些年來，采用或遷移到云原生架構(gòu)的推動(dòng)催生了事件驅(qū)動(dòng)架構(gòu)，其優(yōu)點(diǎn)是組件之間無阻塞通信的良好前景。

使用異步 API，客戶端無需等待響應(yīng)即可繼續(xù)操作，也就是可以發(fā)送請(qǐng)求的同時(shí)繼續(xù)執(zhí)行過程。

這種方法對(duì)于需要高并發(fā)性、可擴(kuò)展性和響應(yīng)性的場景是非常有利的。

在事件驅(qū)動(dòng)的系統(tǒng)中，異步 API 在Apache Kafka或RabbitMQ等工具的幫助下處理事件和消息，這些技術(shù)提供了消息生產(chǎn)者和消費(fèi)者之間的通信媒介。

典型使用事件驅(qū)動(dòng) API 方法的系統(tǒng)原理，先讓生產(chǎn)者將事件發(fā)布到主題，而消費(fèi)者訂閱這些主題，用以異步接收和處理事件。這樣允許無縫的可擴(kuò)展性和容錯(cuò)能力，因?yàn)樯a(chǎn)者和消費(fèi)者都可以獨(dú)立發(fā)展。

下圖就向大家展示了這樣一個(gè)系統(tǒng)：

圖 3 具有 Kafka 和異步 API 的事件驅(qū)動(dòng)系統(tǒng)

異步 API 的優(yōu)點(diǎn)與缺點(diǎn)

異步 API 有如下的關(guān)鍵優(yōu)勢：

• 異步 API 非常適合處理高并發(fā)性和可擴(kuò)展性要求，可以同時(shí)處理多個(gè)請(qǐng)求。
• 異步 API 還可以通過及時(shí)響應(yīng)事件來實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理。
• 異步 API 還可以通過將任務(wù)卸載到后臺(tái)進(jìn)程來幫助更好地利用系統(tǒng)資源。
• 最后，異步 API提高了系統(tǒng)的總體容錯(cuò)能力，當(dāng)一個(gè)組件發(fā)生故障不會(huì)破壞整個(gè)系統(tǒng)。

如同其它 API 類型一樣，異步 API 也存在以下幾個(gè)缺點(diǎn)：

• 消息傳遞、排序和錯(cuò)誤處理的復(fù)雜度增加。
• 異步 API 的調(diào)試和測試更具挑戰(zhàn)性。
• 使用異步 API 構(gòu)建的系統(tǒng)通常會(huì)導(dǎo)致最終一致性，其中數(shù)據(jù)更新不會(huì)立即反映在所有組件中。
• 異步 API 還會(huì)增加處理消息的特殊系統(tǒng)的成本。

異步 API 的典型用例

與 REST 和 GraphQL API 兩種API類型相比，異步 API 也有一些合適的理想用例，包括如下：

• 實(shí)時(shí)數(shù)據(jù)流異步 API 是滿足實(shí)時(shí)數(shù)據(jù)流需求（例如社交媒體數(shù)據(jù)源、金融市場更新和物聯(lián)網(wǎng)傳感器數(shù)據(jù)）的最佳選擇。這些應(yīng)用程序生成大量數(shù)據(jù)，需要近乎實(shí)時(shí)地處理并交付給客戶端。
• 與第三方系統(tǒng)集成更方便異步 API 非常適合與可能具有不可預(yù)測的響應(yīng)時(shí)間，或者可用性 SLA也不夠確定的第三方系統(tǒng)集成。
• 后臺(tái)任務(wù)最后，需要執(zhí)行后臺(tái)任務(wù)（例如發(fā)送郵件、通知或圖像/視頻處理）的應(yīng)用程序者可以從使用異步 API 中受益。

REST、GraphQL 和異步 API 的綜合比較

前面我們已經(jīng)詳細(xì)研究了三種類型的 API 架構(gòu)。現(xiàn)在是時(shí)候?qū)λ鼈冞M(jìn)行并排綜合比較了，以便大家在開發(fā)前做出更好的決策與選擇。

下表顯示了三種類型幾個(gè)關(guān)鍵參數(shù)的比較：

表 1 比較 REST、GraphQL 與異步 API

結(jié)語

在本文中，我們共同探討了不同 API 架構(gòu)之間的主要區(qū)別，分別是：REST、GraphQL 與異步 API。

此外，還詳解了特定類型的 API 可能比其它類型更適合的場景。

展望未來，API 開發(fā)格局有望進(jìn)一步轉(zhuǎn)型，包括機(jī)器學(xué)習(xí)、邊緣計(jì)算和物聯(lián)網(wǎng)等新興技術(shù)將推動(dòng)新的需求，從而推動(dòng) API 方法的更快發(fā)展。此外，隨著分布式系統(tǒng)的高速發(fā)展和升級(jí)，API 將在通信方面發(fā)揮更關(guān)鍵與重要作用。

作為開發(fā)者，了解每種 API 樣式的優(yōu)點(diǎn)和局限性并選擇最適合給定需求的方法非常重要。

這樣的心態(tài)，可以幫助我們充滿信心地駕馭當(dāng)下的 API 領(lǐng)域。

本文章轉(zhuǎn)載微信公眾號(hào)@21CTO

#你可能也喜歡這些API文章!

如何快速實(shí)現(xiàn)REST API集成以優(yōu)化業(yè)務(wù)流程

使用FastAPI為Python構(gòu)建應(yīng)用程序

使用Django REST Framework構(gòu)建API

使用Flask、Google Cloud SQL和App Engine設(shè)置API

微服務(wù)為什么要用到 API 網(wǎng)關(guān)？

14個(gè)文本轉(zhuǎn)圖像AI API

什么是API定義？

修復(fù)API中損壞的訪問控制的指南

前端需要的免費(fèi)在線API接口