2023 API 排行榜新鮮出爐！盤點(diǎn)使用最多的 API 協(xié)議

REST 其實(shí)不是一種協(xié)議，REST  接口使用的網(wǎng)絡(luò)協(xié)議是 HTTP。

HTTP 協(xié)議非常適合那些采用單向的請(qǐng)求 - 響應(yīng)模式的應(yīng)用，比如訪問(wèn)社交媒體上的照片或者新聞文章，但是它并不適合需要雙方實(shí)時(shí)通信的應(yīng)用，比如在線游戲或視頻聊天。

REST 是在開(kāi)發(fā)者使用 HTTP 協(xié)議時(shí)共同遵守的設(shè)計(jì)原則，是一種軟件架構(gòu)風(fēng)格，它并不是一種硬性的技術(shù)標(biāo)準(zhǔn)。REST 風(fēng)格 API 一般長(zhǎng)這個(gè)樣子：

瀏覽器可能是最簡(jiǎn)單的 REST 接口調(diào)用工具。瀏覽器地址欄就是一個(gè)最原始的 GET 請(qǐng)求發(fā)起器，它會(huì)將 GET 返回的數(shù)據(jù)展示在網(wǎng)頁(yè)里。

但是，要實(shí)現(xiàn) POST、PUT、DELETE 等動(dòng)作就要寫代碼了。當(dāng)然，你也可以使用像 Apifox 這樣的 API 工具，一鍵發(fā)起各種類型的 HTTP 請(qǐng)求。

在上面的 REST 接口里，我們需要預(yù)先定義好各種具體的操作的接口（獲取所有用戶，獲取特定用戶，按標(biāo)簽查詢用戶等），就像飯店里固定搭配的套餐。

而 GraphQL 是一種靈活的數(shù)據(jù)查詢語(yǔ)言，讓你可以像點(diǎn)餐一樣精確地獲取你需要的數(shù)據(jù)，好比你在餐館里直接告訴服務(wù)員想要哪些食物，以及烹飪方式，而不是被迫點(diǎn)一份固定的套餐。

GraphQL 適用于那些需要大量互動(dòng)、實(shí)時(shí)數(shù)據(jù)或者多層次數(shù)據(jù)的應(yīng)用。比如社交媒體的實(shí)時(shí)消息更新、即時(shí)通訊或者數(shù)據(jù)可視化工具。它能夠滿足不同應(yīng)用的各種需求，因?yàn)槟憧梢栽谝粋€(gè)請(qǐng)求中包含多個(gè)查詢，從而減少了網(wǎng)絡(luò)請(qǐng)求的數(shù)量。

當(dāng)使用 GraphQL 進(jìn)行數(shù)據(jù)調(diào)用時(shí)，你會(huì)構(gòu)建一個(gè)查詢（Query）來(lái)獲取你需要的數(shù)據(jù)。這個(gè)查詢看起來(lái)類似于一個(gè) JSON 對(duì)象，你可以指定所需的字段和參數(shù)。以下是一個(gè)簡(jiǎn)單的 GraphQL 查詢示例，假設(shè)我們要獲取一個(gè)博客應(yīng)用中的文章信息：

在這個(gè)查詢中：

• query 表示這是一個(gè)查詢操作。

• article(id: 123) 表示我們想要獲取一篇文章，其中 id 參數(shù)為 123。

• 在大括號(hào) {} 內(nèi)，我們指定了想要獲取的字段，如 title、content 和 author。

• 在 author 字段下，我們還指定了作者的信息字段，包括 name 和 email。

當(dāng)發(fā)送這個(gè)查詢到 GraphQL 服務(wù)器時(shí)，服務(wù)器會(huì)返回一個(gè) JSON 響應(yīng)，包含與查詢匹配的數(shù)據(jù)。好比構(gòu)建一個(gè)查詢，指定你需要的數(shù)據(jù)字段，然后向服務(wù)器發(fā)送查詢，并接收服務(wù)器返回的 JSON 響應(yīng)以獲取所需的數(shù)據(jù)。響應(yīng)可能如下所示：

這個(gè)響應(yīng)包含了我們所請(qǐng)求的文章的標(biāo)題、內(nèi)容以及作者的信息。所有數(shù)據(jù)都以嵌套的方式返回，與查詢的結(jié)構(gòu)一致。這種方式允許客戶端精確地獲取所需的數(shù)據(jù)，而不會(huì)浪費(fèi)帶寬和資源。

在 Apifox 中，可以直接使用 HTTP POST 方式發(fā)起 GraphQL API 請(qǐng)求。你只需要將 Body 類型指定為 GraphQL，將請(qǐng)求 JSON 寫入 Query 即可。

你可以在 Query 中使用變量，將變量值寫入 Variables 框，就可以更加便利地調(diào)用固定格式的 GraphQL 請(qǐng)求。

SOAP（Simple Object Access Protocol，簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議）是一種跟 REST 類似，但更古早一點(diǎn)的協(xié)議。它跟 REST 的最大的差異是使用 XML 方式作為 body 來(lái)傳遞信息。它提供了強(qiáng)大的功能，包括安全性、事務(wù)性操作和可擴(kuò)展性，但也因其 XML 格式相對(duì)冗長(zhǎng)而被一些新的通信協(xié)議所取代。

Web Service 是一個(gè)比較古早的名詞，現(xiàn)在一般指使用 SOAP 協(xié)議的接口服務(wù)。

要使用 SOAP/Web Service，你需要定義一個(gè) SOAP 消息的格式，通常使用 XML 來(lái)表示消息的結(jié)構(gòu)和內(nèi)容。消息由一個(gè) envelope（信封）包裹起來(lái)，其中包含了 header（頭部）和 body（主體）部分。header 可用于包含一些元數(shù)據(jù)和安全信息，而 body 包含實(shí)際的數(shù)據(jù)。

在 Apifox 中調(diào)試 SOAP 接口時(shí)，只需要根據(jù)接口實(shí)際情況，手動(dòng)設(shè)置 Header 的 Content-Type 的值為 text/xml; charset=utf-8 或 application/soap+xml，然后設(shè)置 Body 格式為 xml，點(diǎn)擊「發(fā)送」，即可收到 SOAP 接口返回的 XML 格式的數(shù)據(jù)。

無(wú)論是 REST、GraphQL 還是 SOAP，都是一問(wèn)一答式的通信。但有時(shí)我們需要更高頻的數(shù)據(jù)交換，比如實(shí)時(shí)聊天，這時(shí)候就需要一種新的協(xié)議來(lái)解決了。

WebSocket 是一種特殊的通信協(xié)議，它與傳統(tǒng)的 HTTP 協(xié)議不同，它更像是一條電話線，允許服務(wù)器和客戶端之間進(jìn)行實(shí)時(shí)、雙向的對(duì)話。就像是你在打電話，而不只是發(fā)短信。

WebSocket 適合處理需要實(shí)時(shí)性和雙向通信的應(yīng)用，比如在線聊天、多人協(xié)作編輯、在線游戲或者實(shí)時(shí)股票市場(chǎng)數(shù)據(jù)更新。它能夠讓服務(wù)器主動(dòng)向客戶端發(fā)送消息，而不必等待客戶端的請(qǐng)求。這種特性對(duì)于那些需要即時(shí)響應(yīng)的應(yīng)用非常重要。

與 HTTP 不同，WebSocket 不是一次性的請(qǐng)求-響應(yīng)模式。它通過(guò)建立一個(gè)持久連接，雙方可以隨時(shí)發(fā)送消息。這就像是你與朋友進(jìn)行實(shí)時(shí)對(duì)話，而不是發(fā)電子郵件等待回復(fù)。

在 Apifox 中，你可以輸入服務(wù)器 URL，點(diǎn)擊「連接」，一個(gè) Websocket 長(zhǎng)連接就建立起來(lái)了。

接下來(lái)，你可以通過(guò)發(fā)送 JSON 數(shù)據(jù)的方式跟服務(wù)器通信，也可以實(shí)時(shí)接收到服務(wù)器下發(fā)的數(shù)據(jù)，實(shí)現(xiàn)雙向?qū)崟r(shí)數(shù)據(jù)傳輸。你可以在左下角的時(shí)間線視圖里方便地查看所有通信記錄。

Apifox 還支持直接生成 Websocket 協(xié)議的 API 文檔。你可以點(diǎn)擊查看更多使用技巧：《Apifox WebSocket 調(diào)試功能你會(huì)用了嗎？》

當(dāng)我們?cè)谑褂?ChatGPT 聊天的時(shí)候，你會(huì)發(fā)現(xiàn)文字是一個(gè)一個(gè)蹦出來(lái)的，這跟微信聊天又有所不同。

ChatGPT 使用的是 SSE（Server-Sent Events）技術(shù)，全稱是服務(wù)器推送事件，它是一種基于 HTTP 協(xié)議的實(shí)時(shí)通信技術(shù)。用于在客戶端和服務(wù)器之間建立持久、單向的鏈接。雖然和 WebSocket 類似都具備實(shí)時(shí)連接功能，但 WS 是支持雙向連接的，而 SSE 是單向的，只支持服務(wù)端向客戶端發(fā)送異步消息，使得它對(duì)帶寬資源消耗較小。

也就是說(shuō)，WebSocket 是兩個(gè)人互相打電話，而 SSE 是客戶端發(fā)短信，服務(wù)端講電話。

使用 Apifox 調(diào)試 SSE 接口時(shí)，僅需要像調(diào)試普通的 HTTP 接口一樣新建接口。

當(dāng)接口的返回?cái)?shù)據(jù)的 Content-Type 包含 text/event-stream 參數(shù)時(shí)，Apifox 會(huì)自動(dòng)將返回的數(shù)據(jù)解析為 SSE 事件，并以全新的時(shí)間線視圖實(shí)時(shí)更新響應(yīng)內(nèi)容。

前面的各種協(xié)議，大都適用于前端和后端的通信。而 gRPC（gRPC Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）不同，它更多地是用于后端和后端之間的通信。

在大型企業(yè)中，往往使用微服務(wù)架構(gòu)，不同的服務(wù)由不同的系統(tǒng)實(shí)現(xiàn)。比如訂單服務(wù)、商品服務(wù)、用戶信息服務(wù)部署在不同的服務(wù)器上，這些系統(tǒng)可能使用了各自不同的技術(shù)。

gRPC 適合用于構(gòu)建分布式系統(tǒng)中的微服務(wù)架構(gòu)，尤其是需要高性能、低延遲和跨語(yǔ)言通信的情況。與傳統(tǒng)的 HTTP 或 REST API 相比，gRPC 更加輕量級(jí)且高效，它使用 Protocol Buffers（ProtoBuf）作為數(shù)據(jù)序列化格式，這使得數(shù)據(jù)傳輸更加緊湊和快速。

一個(gè)典型的 gRPC 場(chǎng)景包括多個(gè)微服務(wù)之間的通信，例如用戶服務(wù)需要從訂單服務(wù)獲取信息。gRPC 允許你定義服務(wù)接口和方法，并生成客戶端和服務(wù)器端的代碼，使得開(kāi)發(fā)過(guò)程更加簡(jiǎn)化。這就像是國(guó)際郵件服務(wù)，你只需知道如何填寫地址和標(biāo)明信件的內(nèi)容，剩下的工作由郵遞員和郵局來(lái)完成。

在企業(yè)中，后端往往會(huì)使用 gRPC 來(lái)調(diào)用企業(yè)內(nèi)部不同系統(tǒng)之間的服務(wù)，而使用 REST API 來(lái)對(duì)前端提供服務(wù)。

你只需要先在 Apifox 中創(chuàng)建 gRPC 項(xiàng)目即可開(kāi)始調(diào)試：

Apifox 支持以下 4 種類型方法調(diào)用 gRPC 接口：

• Unary：一元調(diào)用

• Server Streaming：服務(wù)端流

• Client Streaming：客戶端流

• Bidirectional Streaming：雙向流

相較于市面上的其它 gRPC 調(diào)試軟件，Apifox 為 gRPC 流式調(diào)用提供了一個(gè)時(shí)間線視圖，按照時(shí)間順序集中展示調(diào)用狀態(tài)、發(fā)送和收到的消息。

Dubbo 框架是由阿里巴巴開(kāi)發(fā)的一款分布式服務(wù)框架，Dubbo 協(xié)議是該框架中的一部分，用于微服務(wù)之間的通信。

Dubbo 協(xié)議的使用場(chǎng)景跟 gRPC 是類似的，主要用于后端之間的通信。兩者都是強(qiáng)大的分布式通信框架，選擇哪一個(gè)取決于你的具體需求和技術(shù)棧。如果你在 Java 生態(tài)系統(tǒng)中工作，并需要穩(wěn)定性和可用性，Dubbo 可能是更好的選擇。如果你需要跨語(yǔ)言支持、強(qiáng)類型定義和高性能的通信，gRPC 可能更適合你。

Dubbo 協(xié)議采用了二進(jìn)制序列化和網(wǎng)絡(luò)傳輸方式，相比 REST API 采用文本模式傳輸數(shù)據(jù)，二進(jìn)制格式數(shù)據(jù)傳輸模式可以提供更高的效能和花費(fèi)更小的開(kāi)銷，非常適合內(nèi)網(wǎng)環(huán)境。

因此 Dubbo 協(xié)議尤其擅長(zhǎng)處理大規(guī)模微服務(wù)架構(gòu)中的服務(wù)調(diào)用和治理問(wèn)題，支持多種主流網(wǎng)絡(luò)傳輸協(xié)議和多種序列化格式，在國(guó)內(nèi)的后端開(kāi)發(fā)者當(dāng)中十分流行。

Apifox 支持管理與調(diào)試 Dubbo 項(xiàng)目，目前支持 ZooKeeper、Nacos、阿里云 EDAS 三種外部導(dǎo)入渠道。

導(dǎo)入接口后，點(diǎn)擊右上角的「調(diào)用」按鈕，即可得到接口的返回結(jié)果。

MsgPack（MessagePack）也不是協(xié)議。它是一種將數(shù)據(jù)序列化成緊湊的二進(jìn)制格式的開(kāi)放標(biāo)準(zhǔn)。它就像是將數(shù)據(jù)壓縮成小巧的包裹，以便于在不同系統(tǒng)之間更快地傳輸和存儲(chǔ)。MsgPack 適合用于需要高效傳輸數(shù)據(jù)的場(chǎng)景，尤其對(duì)網(wǎng)絡(luò)流量敏感的移動(dòng) APP 中。與 JSON 等文本格式相比，MsgPack 的二進(jìn)制格式更加緊湊，節(jié)省了更多帶寬和存儲(chǔ)空間。

一些典型的使用場(chǎng)景包括：

1. 分布式系統(tǒng)通信：MsgPack 可用于在不同的服務(wù)之間傳輸數(shù)據(jù)，減少網(wǎng)絡(luò)負(fù)載，提高通信效率。

2. 高性能應(yīng)用：對(duì)于需要快速序列化和反序列化數(shù)據(jù)的應(yīng)用，MsgPack 提供了比文本格式更快的速度。

3. 數(shù)據(jù)存儲(chǔ)：MsgPack 可以用于將數(shù)據(jù)緊湊地存儲(chǔ)在文件或數(shù)據(jù)庫(kù)中，節(jié)省存儲(chǔ)空間。

4. 嵌入式系統(tǒng)：MsgPack 適用于資源有限的嵌入式系統(tǒng)，因?yàn)樗慕馕鱿鄬?duì)輕量。

MsgPack 有多種語(yǔ)言的實(shí)現(xiàn)，因此可以輕松地在不同編程語(yǔ)言之間進(jìn)行數(shù)據(jù)交換。它還支持多種數(shù)據(jù)類型，包括數(shù)字、字符串、數(shù)組、映射和自定義類型，使得它非常靈活。

在 Apifox 中，可以直接使用 HTTP POST 方式發(fā)起 MsgPack 請(qǐng)求，只需要將 Body 類型選擇為 MsgPack，將請(qǐng)求 JSON 寫入 Query 即可。

以上列出了九種常用的 API 協(xié)議/接口規(guī)范，Apifox 現(xiàn)已全部支持。

Apifox 作為先進(jìn)的 API 設(shè)計(jì)/開(kāi)發(fā)/測(cè)試工具，不斷兼容市面上流行的 API 協(xié)議，讓開(kāi)發(fā)人員不必再為某個(gè) API 協(xié)議而苦苦尋找接口調(diào)試工具。

Apifox = Postman + Swagger + Mock + JMeter

一個(gè)工具就可以解決 API 開(kāi)發(fā) → 調(diào)試 → 管理問(wèn)題，讓更多中國(guó)開(kāi)發(fā)團(tuán)隊(duì)也能夠體驗(yàn)到一流的一站式 API 管理方案。

官方鏈接：http://apifox.com/b3xiaohaxy

想了解更多關(guān)于 Apifox 的內(nèi)容，可以點(diǎn)擊「閱讀原文」前往 Apifox 官網(wǎng)查看。