構(gòu)建 API 是現(xiàn)代工程中開(kāi)發(fā)人員的最重要任務(wù)之一。這些 API 允許不同的系統(tǒng)進(jìn)行通信和數(shù)據(jù)交換。雖然 REST 多年來(lái)一直是實(shí)現(xiàn) API 的事實(shí)標(biāo)準(zhǔn)，但今天也有新興的標(biāo)準(zhǔn)，如 gRPC 和 GraphQL。

什么是 API？

“應(yīng)用程序編程接口”（API）是各種軟件服務(wù)之間的通信渠道。傳輸請(qǐng)求和響應(yīng)的應(yīng)用程序分別稱(chēng)為客戶端和服務(wù)器。API 是一個(gè)外部軟件組件，使程序功能可供其他程序使用。

在下面的蜜蜂 ?? 插圖中，花朵充當(dāng)服務(wù)器，蜂巢充當(dāng)客戶端，蜜蜂提供通信手段（REST API 請(qǐng)求）。

什么是 API？（圖片來(lái)源：Rapid API）

存在不同的 API 架構(gòu)或協(xié)議，如 REST、gRPC 和 GraphQL。

為什么 gRPC 很重要？

gRPC 是由 Google 開(kāi)發(fā)的高性能、開(kāi)源、通用遠(yuǎn)程過(guò)程調(diào)用（RPC）框架。它使用 Protocol Buffers (protobuf) 作為其接口定義語(yǔ)言。協(xié)議緩沖區(qū)是一種非常有效和快速的網(wǎng)絡(luò)數(shù)據(jù)序列化方式。這項(xiàng)技術(shù)使用 HTTP 2.0 協(xié)議 實(shí)現(xiàn)了 RPC API；然而，服務(wù)器和 API 開(kāi)發(fā)者都無(wú)法訪問(wèn) HTTP。它遵循 客戶端-響應(yīng)通信模型，由于 gRPC 能夠接收來(lái)自多個(gè)客戶端的多個(gè)請(qǐng)求并同時(shí)處理它們，因此支持雙向通信和流媒體。然而，gRPC 在瀏覽器支持方面仍然 相當(dāng)有限。

如前所述，gRPC 默認(rèn)使用 Protocol Buffers 來(lái)序列化有效載荷數(shù)據(jù)。Protocol Buffers 是緊湊的二進(jìn)制序列化格式，用于結(jié)構(gòu)化數(shù)據(jù)。它們使用在 .proto 文件中定義的模式，允許在不同語(yǔ)言之間進(jìn)行高效的編碼和解碼。它們提供了比傳統(tǒng)的 JSON 或 XML 更小的尺寸和更快的處理速度等優(yōu)勢(shì)。

gRPC 的優(yōu)點(diǎn)：

• 速度：由于 HTTP/2，gRPC 比 HTTP/1.1 上的 REST 更快、更高效。
• 多語(yǔ)言支持：提供工具在多種語(yǔ)言中生成客戶端和服務(wù)器代碼。
• 流媒體： 支持雙向流媒體，允許更互動(dòng)的實(shí)時(shí)通信。
• 截止時(shí)間/超時(shí)： 內(nèi)置支持確保請(qǐng)求不會(huì)掛起。它自動(dòng)解決重試、網(wǎng)絡(luò)問(wèn)題等。
• 生態(tài)系統(tǒng)： 支持身份驗(yàn)證、負(fù)載均衡等。

gRPC 的缺點(diǎn)：

• 復(fù)雜： 您必須了解 Protocol Buffers 和 gRPC API。還必須預(yù)先定義模式。
• 瀏覽器支持有限： 由于依賴 HTTP/2，原生瀏覽器支持有限。
• 工具： 雖然在增長(zhǎng)，但 gRPC 工具的成熟度不如 REST。您可以使用 gRPCurl 或 Postman 來(lái)測(cè)試這些 API。
• 不可讀性： 由于它們是二進(jìn)制的，它們難以調(diào)試，就像您可以使用基于文本的格式（如 XML 或 JSON）那樣。

gRPC

什么是 Protocol Buffers?

Protocol Buffers，通?？s寫(xiě)為 Protobuf，是 Google 在 2008 年設(shè)計(jì)的一種序列化結(jié)構(gòu)化數(shù)據(jù)的方法。與 XML 或 JSON 類(lèi)似，它們更精簡(jiǎn)、更快，因?yàn)樗鼈兪嵌M(jìn)制的，使它們成為與服務(wù)器通信或高效存儲(chǔ)數(shù)據(jù)的應(yīng)用程序的首選。

使用 Protocol Buffers 進(jìn)行數(shù)據(jù)序列化涉及幾個(gè)步驟：

• 定義數(shù)據(jù)結(jié)構(gòu)：您從在 .proto 文件中定義數(shù)據(jù)結(jié)構(gòu)開(kāi)始。這包括指定數(shù)據(jù)類(lèi)型(整數(shù)、字符串、布爾值、自定義類(lèi)型等)及其字段編號(hào)。
• 生成源代碼：使用 Protocol Buffers 編譯器(protoc)從文件中生成您所需語(yǔ)言的源代碼。編譯器可以為多種語(yǔ)言生成代碼，包括 Java、C++、Python 等。
• 生成可執(zhí)行包：可執(zhí)行包也是與 Protobuf 代碼生成的源文件一起生成和部署的。在運(yùn)行時(shí)，消息以二進(jìn)制格式序列化和壓縮。
• 反序列化： 當(dāng)接收方收到序列化的數(shù)據(jù)流時(shí)，他們可以使用生成的類(lèi)輕松地將其轉(zhuǎn)換回結(jié)構(gòu)化格式。

什么是 REST API？

REST（Representational State Transfer，表述性狀態(tài)傳遞）不是一個(gè)框架或庫(kù)，而是一種用于構(gòu)建 Web 服務(wù)和 API 的架構(gòu)風(fēng)格。在 REST 中，一切都是 由唯一 URL 標(biāo)識(shí)的資源，這些資源使用 HTTP 方法（如 GET（檢索資源）、POST（創(chuàng)建新資源）、PUT 或 PATCH（更新資源）和 DELETE（移除資源））進(jìn)行操作。

客戶端到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解和完成請(qǐng)求所需的所有信息。服務(wù)器不存儲(chǔ)請(qǐng)求之間的客戶端上下文，簡(jiǎn)化了設(shè)計(jì)并提高了可伸縮性?？蛻舳撕头?wù)器的 HTTP 請(qǐng)求和響應(yīng)體攜帶 JSON 或 XML 表示 資源的狀態(tài)。

在他的 博士論文中，計(jì)算機(jī)科學(xué)家 Roy Fielding 在 2000 年介紹并定義了表述性狀態(tài)傳遞。 REST API 的好處：

• 簡(jiǎn)單性： 使用標(biāo)準(zhǔn) HTTP 方法和常見(jiàn)數(shù)據(jù)格式使 REST API 易于理解和實(shí)現(xiàn)。
• 互操作性： REST API 促進(jìn)了互操作性，因?yàn)椴煌膽?yīng)用程序可以無(wú)縫交互，無(wú)論使用的是哪種編程語(yǔ)言或平臺(tái)。
• 可伸縮性： REST API 的無(wú)狀態(tài)性質(zhì)允許輕松擴(kuò)展以處理大量請(qǐng)求。
• 靈活性： 由于其多功能設(shè)計(jì)原則，REST API 可以適應(yīng)各種用例。

REST API 的缺點(diǎn)：

• 無(wú)狀態(tài)性： REST 依賴于無(wú)狀態(tài)事務(wù)，這意味著每個(gè)請(qǐng)求都必須獨(dú)立完成所有信息。對(duì)于需要在多個(gè)請(qǐng)求之間維護(hù)狀態(tài)的工作流程(如電子商務(wù)網(wǎng)站上的購(gòu)物車(chē))來(lái)說(shuō)，這可能很麻煩。
• 有效載荷大小有限： REST 中的數(shù)據(jù)傳輸通常通過(guò) JSON 或 XML 有效載荷進(jìn)行，如果您處理復(fù)雜數(shù)據(jù)或多個(gè)查詢，這可能會(huì)變得相當(dāng)大。這可能導(dǎo)致性能問(wèn)題。
• 可發(fā)現(xiàn)性不足： REST API 本身并不容易讓用戶理解其功能或如何與之交互，這可能會(huì)為新用戶增加復(fù)雜性。
• 復(fù)雜查詢的性能： 對(duì)于從較大資源中檢索特定數(shù)據(jù)點(diǎn)，REST 可能不是理想選擇。其他選項(xiàng)，如 GraphQL，在這種情況下可能更有效。

REST 定義了一個(gè) API 應(yīng)該遵循的 六個(gè)架構(gòu)約束，以被認(rèn)為是真正的 RESTful：

(1) 客戶端-服務(wù)器： 這種關(guān)注點(diǎn)的分離將客戶端(使用 API 的應(yīng)用程序)與服務(wù)器(提供 API 的應(yīng)用程序)分開(kāi)?？蛻舳税l(fā)起請(qǐng)求，服務(wù)器處理并發(fā)送響應(yīng)。

(2) 無(wú)狀態(tài)： 客戶端到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解請(qǐng)求所需的所有信息。服務(wù)器不存儲(chǔ)有關(guān)客戶端的任何上下文。這簡(jiǎn)化了通信并提高了可伸縮性。

(3) 統(tǒng)一接口： 此約束定義了一組規(guī)則，規(guī)定客戶端如何與服務(wù)器交互。這些規(guī)則包括：

• 基于資源： API 暴露客戶端可以交互的資源。URL 標(biāo)識(shí)資源。
• 標(biāo)準(zhǔn)方法： 客戶端使用標(biāo)準(zhǔn) HTTP 方法(GET、POST、PUT、DELETE)對(duì)資源進(jìn)行操作。
• 表示： 客戶端和服務(wù)器之間的數(shù)據(jù)以 JSON 或 XML 等標(biāo)準(zhǔn)格式交換。

(4) 可緩存： 客戶端可以將服務(wù)器響應(yīng)標(biāo)記為可緩存。這允許客戶端本地存儲(chǔ)頻繁訪問(wèn)的數(shù)據(jù)，減輕服務(wù)器負(fù)載并提高性能。

(5) 分層系統(tǒng)： 架構(gòu)可能包括客戶端和服務(wù)器之間的多個(gè)層次(代理、緩存、負(fù)載均衡器)。這些層可以提高性能、安全性和可伸縮性。

(6) 按需代碼(可選)： 雖然不是嚴(yán)格必需的，但 RESTful API 可以選擇性地將可執(zhí)行代碼傳輸給客戶端?？蛻舳丝梢允褂么舜a擴(kuò)展其功能或本地處理數(shù)據(jù)。

REST 架構(gòu)約束

REST API 調(diào)用的一個(gè)例子 是當(dāng)我們想要獲取 ID 為 500 的用戶信息時(shí)，使用 curl 命令行工具為 https://api.example.com 地址上的 API 發(fā)出的請(qǐng)求：curl -X GET https://api.example.com/users/500 -H "Accept: application/json"。最后一部分（Accept: application/json）是一個(gè)頭部，表明客戶端期望以 JSON 格式接收數(shù)據(jù)。響應(yīng)將是 JSON 格式的結(jié)果，200 將是響應(yīng)狀態(tài)碼。

REST API 架構(gòu)

即使在性能至關(guān)重要時(shí) REST 不是最佳選擇，我們?nèi)匀豢梢栽谶@里做一些事情，如 緩存、分頁(yè)、有效載荷壓縮 等。

什么是 GraphQL？

GraphQL 是一種用于 API 的查詢語(yǔ)言，由 Meta 在 2015 年發(fā)布并開(kāi)源。現(xiàn)在由 GraphQL 基金會(huì) 監(jiān)督。GraphQL 是一個(gè)服務(wù)器端運(yùn)行時(shí)環(huán)境，使客戶端能夠從 API 請(qǐng)求所需的數(shù)據(jù)。與傳統(tǒng)的 REST API 不同，后者通常需要多個(gè)請(qǐng)求來(lái)獲取不同的數(shù)據(jù)片段，GraphQL 允許您在單個(gè)請(qǐng)求中指定所需的所有數(shù)據(jù)。GraphQL 規(guī)范在 2015 年開(kāi)源。

因?yàn)?GraphQL 在向 API 發(fā)送查詢時(shí)不會(huì)過(guò)度或不足地獲取結(jié)果，它保證了使用 GraphQL 構(gòu)建的應(yīng)用程序是 可伸縮、快速和穩(wěn)定 的。它還允許將多個(gè)操作組合成單個(gè) HTTP 請(qǐng)求。

GraphQL API 按照 類(lèi)型和字段 組織，而不是端點(diǎn)。使用 GraphQL Schema Definition Language (SDL)，您將數(shù)據(jù)定義為模式。這個(gè)模式作為客戶端和服務(wù)器之間的契約，詳細(xì)說(shuō)明了可以進(jìn)行哪些查詢、可以獲取哪些類(lèi)型的數(shù)據(jù)以及響應(yīng)將是什么樣子。

GraphQL 的好處：

• 高效的數(shù)據(jù)獲?。?您只請(qǐng)求確切需要的數(shù)據(jù)，消除了 REST 可能發(fā)生的過(guò)度獲取或不足獲取的問(wèn)題。這可以顯著提高性能，尤其是對(duì)于復(fù)雜的數(shù)據(jù)模型。
• 靈活和聲明性： GraphQL 使用定義可用數(shù)據(jù)及其訪問(wèn)方式的模式。這個(gè)模式允許開(kāi)發(fā)人員編寫(xiě)清晰、簡(jiǎn)潔的查詢，指定他們確切的數(shù)據(jù)需求。
• 單個(gè)請(qǐng)求用于多個(gè)資源： 與 REST 不同，后者需要多個(gè) API 調(diào)用來(lái)從不同端點(diǎn)獲取數(shù)據(jù)，GraphQL 允許將查詢組合成單個(gè)請(qǐng)求以提高效率。
• 版本控制和向后兼容性： 可以通過(guò)版本控制實(shí)現(xiàn) GraphQL 模式更改，確保現(xiàn)有客戶端不受影響，同時(shí)允許未來(lái)增長(zhǎng)。

GraphQL 的缺點(diǎn)：

• 查詢結(jié)構(gòu)的復(fù)雜性： 雖然靈活性是一個(gè)優(yōu)勢(shì)，但編寫(xiě)復(fù)雜的 GraphQL 查詢可能具有挑戰(zhàn)性，并且需要仔細(xì)規(guī)劃以提高可讀性和可維護(hù)性。
• 緩存： 與利用內(nèi)置 HTTP 緩存機(jī)制的 REST API 相比，GraphQL 的數(shù)據(jù)緩存通常更復(fù)雜。
• 安全性： GraphQL 暴露了您的整個(gè)數(shù)據(jù)模式，因此必須采取適當(dāng)?shù)陌踩胧┮苑乐刮唇?jīng)授權(quán)的訪問(wèn)敏感數(shù)據(jù)。
• 學(xué)習(xí)曲線： 對(duì)于不熟悉 GraphQL 的開(kāi)發(fā)人員，理解模式和查詢語(yǔ)法涉及學(xué)習(xí)曲線。
• 錯(cuò)誤處理： 如果庫(kù)不解析響應(yīng)體中狀態(tài)為 200 的錯(cuò)誤，則客戶端必須使用更復(fù)雜的邏輯來(lái)處理它們。

它是如何工作的：

• 客戶端使用GraphQL語(yǔ)法定義查詢，精確指定數(shù)據(jù)應(yīng)如何結(jié)構(gòu)化以及需要哪些字段。
• GraphQL服務(wù)器使用預(yù)定義的模式來(lái)確定可用的數(shù)據(jù)及其與其他數(shù)據(jù)的關(guān)系。這個(gè)模式定義了類(lèi)型、字段以及類(lèi)型之間的關(guān)系。
• 服務(wù)器根據(jù)模式執(zhí)行查詢。對(duì)于查詢中的每個(gè)字段，服務(wù)器都有一個(gè)相應(yīng)的解析函數(shù)來(lái)獲取該字段的數(shù)據(jù)。
• 服務(wù)器返回一個(gè)JSON對(duì)象，其結(jié)構(gòu)直接反映了查詢內(nèi)容，填充了請(qǐng)求的數(shù)據(jù)。

GraphQL支持三種核心操作，定義了客戶端如何與服務(wù)器交互：

• 查詢（Queries）： 用于從服務(wù)器檢索數(shù)據(jù)。這是GraphQL中最常用的操作。
• 變更（Mutations）： 在服務(wù)器上修改數(shù)據(jù)。這可能涉及創(chuàng)建新數(shù)據(jù)、更新現(xiàn)有數(shù)據(jù)或刪除數(shù)據(jù)。
• 訂閱（Subscriptions）： 用于在客戶端和服務(wù)器之間建立實(shí)時(shí)通信。服務(wù)器可以在請(qǐng)求的數(shù)據(jù)發(fā)生變化時(shí)更新客戶端。

GraphQL請(qǐng)求的一個(gè)示例包括一個(gè)操作和你請(qǐng)求或操作的數(shù)據(jù)，例如：

這個(gè)查詢檢索ID為1的用戶的數(shù)據(jù)。它還獲取了該用戶帖子的嵌套數(shù)據(jù)，包括它們的ID和標(biāo)題。

響應(yīng)是一個(gè)JSON對(duì)象，包含查詢或變更請(qǐng)求的實(shí)際數(shù)據(jù)和可選錯(cuò)誤。

要了解更多關(guān)于GraphQL的信息，可以查看Eve Porcello和Alex Banks的書(shū)籍“Learning GraphQL”。

何時(shí)應(yīng)使用GraphQL、gRPC和REST？

開(kāi)發(fā)者在設(shè)計(jì)應(yīng)用程序時(shí)可以選擇多種客戶端-服務(wù)器通信協(xié)議。在當(dāng)代項(xiàng)目中，使用GraphQL、gRPC和REST相對(duì)常見(jiàn)。每種協(xié)議根據(jù)您的應(yīng)用程序需求可以提供不同的優(yōu)勢(shì)。

• GraphQL 是一種靈活的數(shù)據(jù)請(qǐng)求方法，專(zhuān)注于特定請(qǐng)求并僅提供所需數(shù)據(jù)。它的客戶端驅(qū)動(dòng)特性使其與其他API區(qū)別開(kāi)來(lái)?？蛻舳俗龀鏊袥Q策，而不是處理它們。GraphQL的優(yōu)勢(shì)在于它與語(yǔ)言無(wú)關(guān)，請(qǐng)求通過(guò)單一端點(diǎn)進(jìn)行，并且是強(qiáng)類(lèi)型的，因?yàn)樗心Ｊ健?/li>
• REST 是最受歡迎的一個(gè)。當(dāng)一個(gè)領(lǐng)域可以被描述為一組資源時(shí)，它是一個(gè)很好的選擇。REST是一種用于數(shù)據(jù)傳輸?shù)臒o(wú)狀態(tài)架構(gòu)。它的優(yōu)勢(shì)包括是一個(gè)成熟的標(biāo)準(zhǔn)、簡(jiǎn)單易用和良好的緩存支持。
• gRPC 是一個(gè)輕量級(jí)且快速的數(shù)據(jù)獲取系統(tǒng)。這里的主要區(qū)別是它如何描述其合同談判。它依賴于合同；架構(gòu)不是管理談判的內(nèi)容；它是服務(wù)器和客戶端之間的關(guān)系。雖然處理和計(jì)算被委托給遠(yuǎn)程服務(wù)器，但大部分能力用于客戶端。它的主要優(yōu)勢(shì)是它有輕量級(jí)客戶端，高效率，使用協(xié)議緩沖區(qū)來(lái)發(fā)送/接收數(shù)據(jù)，而且是開(kāi)源的。

下圖顯示了最常見(jiàn)的API架構(gòu)風(fēng)格的時(shí)間線。

API架構(gòu)風(fēng)格時(shí)間線

因此，何時(shí)選擇這些協(xié)議中的每一個(gè)：

• 如果您正在構(gòu)建一個(gè)CRUD風(fēng)格的Web應(yīng)用程序或您處理結(jié)構(gòu)化數(shù)據(jù)良好，使用REST。它是公共API和需要被廣泛客戶端消費(fèi)的服務(wù)的首選。
• 如果您的API是私有的并且關(guān)于行動(dòng)或性能至關(guān)重要，使用gRPC。服務(wù)器到服務(wù)器通信的低延遲至關(guān)重要。它使用HTTP/2和ProtoBuf優(yōu)化了效率和速度。
• 如果您有一個(gè)公共API，需要在定制請(qǐng)求方面靈活，并希望將不同來(lái)源的數(shù)據(jù)添加到公共API中，請(qǐng)使用GraphQL。在客戶端-服務(wù)器通信中使用它，我們必須在單次往返中獲取所有數(shù)據(jù)。

gRPC與REST與GraphQL比較