在軟件開發(fā)過程中，對于各類 API 的調(diào)試工作至關(guān)重要。API 調(diào)試是驗(yàn)證和測試應(yīng)用程序接口的有效性和正確性的關(guān)鍵步驟。傳統(tǒng)的 API 調(diào)試方法通常依賴于獨(dú)立的工具或桌面應(yīng)用程序，限制了調(diào)試過程的靈活性和效率。

為推動 API 調(diào)試向更便捷、高效的方向發(fā)展，越來越多的開發(fā)人員開始尋求在純 Web 端完成各類 API 調(diào)試的解決方案。純 Web 端的 API 調(diào)試具有許多優(yōu)勢，包括無需安裝額外軟件、跨平臺支持、便于團(tuán)隊(duì)協(xié)作等。本文將以開源項(xiàng)目 AREX 為例為大家介紹如何在 Web 端實(shí)現(xiàn)對各類 API 的調(diào)試功能。

AREX （http://arextest.com/）是一款開源的基于真實(shí)請求與數(shù)據(jù)的自動化回歸測試平臺，利用 Java Agent 技術(shù)與比對技術(shù)，通過流量錄制回放能力實(shí)現(xiàn)快速有效的回歸測試。同時提供了接口測試、接口比對測試等豐富的自動化測試功能。

難點(diǎn)一：跨域限制

要想在純 Web 端實(shí)現(xiàn)各類 API 的調(diào)試工作，首先要解決的難題是處理瀏覽器的跨域限制。

什么是跨域

瀏覽器跨域問題是指在 Web 開發(fā)中，當(dāng)使用 JavaScript 代碼從一個域名的網(wǎng)頁訪問另一個域名的資源時會遇到的限制。瀏覽器實(shí)施了一種安全策略，稱為同源策略（Same-Origin Policy）， 用于保護(hù)用戶信息的安全。同源策略要求網(wǎng)頁中的 JavaScript 只能訪問與其來源（協(xié)議、域名和端口號）相同的資源，而對于不同域名的資源訪問會受到限制。

由于瀏覽器存在跨域限制，我們不能在瀏覽器端隨心所欲地發(fā)送 HTTP 請求，這是瀏覽器的安全策略決定的。

解決方案

經(jīng)調(diào)研，突破此限制的方法有兩種：分別是 Chrome 插件代理和服務(wù)端代理，以下是兩種方法的比較。

權(quán)衡下來 AREX 選擇了 Chrome 插件代理的方法，其原理是利用了 Chrome 插件中 background 可以發(fā)送跨域請求的能力，我們將瀏覽器端攔截到的請求通過 window.postmassage 與 Chrome 插件的 background 進(jìn)行通信（其中通信還需要 Chrome 插件的 content-script 作為數(shù)據(jù)橋梁）。

具體實(shí)現(xiàn)如下：

在頁面腳本中

生成一個隨機(jī)的字符串，并將其轉(zhuǎn)換為字符串形式，存儲在 tid 變量中。

使用 window.postMessage() 方法發(fā)送一條消息到其他擴(kuò)展程序，消息包括一個類型為 `AREX_EXTENSION_REQUEST` 的標(biāo)識、tid、以及 params 參數(shù)。

添加一個 message 事件監(jiān)聽器 receiveMessage，用于接收其他擴(kuò)展程序發(fā)送的消息。

在 receiveMessage 函數(shù)中，檢查接收到的消息是否為類型為 AREX_EXTENSION_RES，并且 tid 與之前發(fā)送的消息的tid 相匹配。如果匹配成功，則移除事件監(jiān)聽器。

在內(nèi)容腳本中

在后臺腳本中

難點(diǎn)二：API 調(diào)試

上述已經(jīng)解決了跨域問題，接下來就是如何實(shí)現(xiàn) API 調(diào)試的功能。

解決方案

Postman 是業(yè)內(nèi)成熟的 API 調(diào)試工具，我們站在了 Postman 這位巨人的肩膀上，在 AREX 中引入了 Postman 的 JavaScript 沙盒，使用它的沙盒運(yùn)行前置腳本、后置腳本以及斷言來調(diào)試 API。

以下是 AREX 請求的流程圖：

當(dāng)點(diǎn)擊發(fā)送請求的時候，會將表單中的數(shù)據(jù)匯聚到一起，數(shù)據(jù)結(jié)構(gòu)為：

這是 AREX 的數(shù)據(jù)結(jié)構(gòu)，我們會將其轉(zhuǎn)換成 Postman 的數(shù)據(jù)結(jié)構(gòu)。之后調(diào)用 PostmanRuntime.Runner() 方法，將轉(zhuǎn)換好了的 Postman 數(shù)據(jù)結(jié)構(gòu)和當(dāng)前所選的環(huán)境變量傳入，Runner 會執(zhí)行 preRequestScript 和 testScript 腳本。`preRequestScript` 發(fā)生在請求之前，可以在其中穿插請求以及對請求參數(shù)、環(huán)境變量進(jìn)行操作，`testScript` 發(fā)生在請求之后，可以對 response 返回數(shù)據(jù)進(jìn)行斷言操作，并且腳本中也可以通過 `console.log` 輸出數(shù)據(jù)，在控制臺進(jìn)行調(diào)試。

在 Postman 沙盒中也存在跨域問題，由于 Postman 沙盒的集成度非常高，為了確保與 PostmanRuntime 的同步以及方便性，我們采用了 Ajax 攔截技術(shù)。通過在瀏覽器端攔截 Ajax 請求，我們可以對請求進(jìn)行修改、添加自定義邏輯或者進(jìn)行其他處理操作。這樣可以實(shí)現(xiàn)對請求和響應(yīng)的全局控制和定制化。

當(dāng) Postman 沙盒發(fā)送請求時，會攜帶一個名為 "postman-token" 的請求頭。我們攔截到這個 Ajax 請求后，會將請求參數(shù)進(jìn)行拼裝，并通過 window.postMessage 發(fā)送給瀏覽器插件。瀏覽器插件再次構(gòu)建 fetch 請求，將數(shù)據(jù)返回給 Postman 沙盒，使其輸出最終結(jié)果，包括響應(yīng)（response）、測試結(jié)果（testResult）和控制臺日志（console.log）。需要注意的是，responseType 必須指定為 arraybuffer。

具體流程如下：

使用 xspy.onRequest() 方法注冊一個請求處理程序。這個處理程序接受兩個參數(shù)：request 和 sendResponse。request 參數(shù)包含請求的相關(guān)信息，例如方法、URL、頭部、請求體等。sendResponse 是一個回調(diào)函數(shù)，用于發(fā)送響應(yīng)給請求方。

在處理程序中，通過檢查請求的頭部中是否存在 postman-token 來判斷請求是否來自 Postman。

如果存在該頭部，表示請求是通過 Postman 發(fā)送的。則使用 AgentAxios 發(fā)起一個新的請求，使用原始請求的方法、URL、頭部和請求體。AgentAxios 返回一個 agentData 對象，其中包含了響應(yīng)的狀態(tài)碼、頭部和數(shù)據(jù)等信息。創(chuàng)建一個名為 dummyResponse 的響應(yīng)對象，包含了與原始請求相關(guān)的信息。dummyResponse 的 status 字段為 agentData 的狀態(tài)碼，headers 字段為將 agentData 的頭部數(shù)組轉(zhuǎn)換為對象格式的結(jié)果，ajaxType 字段為字符串 xhr，responseType 字段為字符串 arraybuffer，response 字段為將 agentData 的數(shù)據(jù)轉(zhuǎn)換為 JSON 字符串并用 Buffer 包裝的結(jié)果。最后，使用 sendResponse(dummyResponse) 將響應(yīng)發(fā)送給請求方。

如果請求不是來自 Postman，則直接調(diào)用 sendResponse()，表示不返回任何響應(yīng)。

難點(diǎn)三：二進(jìn)制對象序列化傳遞

還有一點(diǎn)值得一提，對于 `x-www-form-urlencoded` 和 `Raw` 類型的請求，由于它們都是普通的 JSON 對象，處理起來比較容易。但是對于 `form-data` 和 `binary` 類型的請求，需要支持傳輸二進(jìn)制文件負(fù)載。然而，Chrome 插件的 `postMessage` 通信方式不支持直接傳遞二進(jìn)制對象，導(dǎo)致無法直接處理這兩種類型的請求。

解決方案

為了解決這個問題，AREX 采用了 base64 編碼技術(shù)。在用戶選擇文件時，AREX 會將二進(jìn)制文件轉(zhuǎn)換為 base64 字符串，然后進(jìn)行傳輸。在 Chrome 插件端，AREX 會將 base64 數(shù)據(jù)進(jìn)行解碼，并用于構(gòu)建實(shí)際的 `fetch` 請求。這樣可以繞過直接傳遞二進(jìn)制對象的限制。

就這個問題我們采用了 base64 編碼技術(shù)，在選擇文件時我們會將二進(jìn)制文件轉(zhuǎn)換成 base64 字符串，再進(jìn)行傳輸，Chrome 插件端會將 base64 數(shù)據(jù)解碼并用于構(gòu)建實(shí)際的 `fetch` 請求。

這個流程圖描述了將 FormData 中的二進(jìn)制文件轉(zhuǎn)換為 Base64 字符串，并通過 Chrome 插件代理將其轉(zhuǎn)換回文件并進(jìn)行進(jìn)一步處理的過程。

form-data binary（A）：表示一個包含二進(jìn)制文件的 FormData 表單數(shù)據(jù)。

FileReader（B）：使用 FileReader 對象來讀取二進(jìn)制文件。

readAsDataURL base64 string：FileReader 使用 readAsDataURL 方法將二進(jìn)制文件讀取為 Base64 字符串。

Chrome 插件代理（C）：Base64 字符串經(jīng)過讀取操作后，傳遞給 Chrome 插件代理進(jìn)行進(jìn)一步處理。

base64 string：表示經(jīng)過 FileReader 讀取二進(jìn)制文件后得到的 Base64 字符串。

Uint8Array（D）：在 Chrome 插件代理中，將 Base64 字符串轉(zhuǎn)換為 Uint8Array。

File（E）：使用 Uint8Array 的數(shù)據(jù)創(chuàng)建一個新的 File 對象。

fetch（F）：將新創(chuàng)建的 File 對象通過 fetch 方法或其他方式進(jìn)行進(jìn)一步處理，例如上傳到服務(wù)器或進(jìn)行其他操作。

代碼分析

以下是代碼層面的分析：

toBase64 函數(shù)接受一個 File 對象作為參數(shù)，并返回一個 Promise 對象，該 Promise 對象將解析為表示文件的 Base64 字符串。

在函數(shù)內(nèi)部，創(chuàng)建了一個 FileReader 對象。通過調(diào)用 reader.readAsDataURL(file) 將文件讀取為 Data URL。當(dāng)讀取操作完成時，通過 reader.onload 事件處理程序?qū)⒆x取結(jié)果解析為字符串，并使用 resolve 將其傳遞給 Promise。如果發(fā)生錯誤，將使用 reject 將錯誤傳遞給 Promise。base64ToFile 函數(shù)接受兩個參數(shù)：dataurl（Base64 字符串）和 filename（文件名），并返回一個 File 對象。

首先，將 dataurl 使用逗號分割成數(shù)組 arr，如果分割結(jié)果為空，則將其設(shè)為包含一個空字符串的數(shù)組。通過正則表達(dá)式匹配 arr[0] 中的內(nèi)容，提取出 MIME 類型，即數(shù)據(jù)的類型。

使用 atob 將 Base64 字符串解碼為二進(jìn)制字符串 bstr。創(chuàng)建一個長度為 n 的 Uint8Array 數(shù)組 u8arr。使用循環(huán)遍歷 bstr，將每個字符的 Unicode 編碼放入 u8arr 中。

最后，使用 File 構(gòu)造函數(shù)創(chuàng)建并返回一個新的 File 對象，其中包含了從 u8arr 中讀取的文件數(shù)據(jù)、文件名和 MIME 類型。導(dǎo)出 base64ToFile 函數(shù)，以便在其他地方使用。

以上就是如何實(shí)現(xiàn)在純Web端完成各類API調(diào)試？的詳細(xì)內(nèi)容，更多關(guān)于web調(diào)用api接口實(shí)例的資料請關(guān)注腳本之家其它相關(guān)文章！

你可能感興趣的文章

• 

  Web3無助記詞錢包：安全性和便捷度的取舍

  這篇文章主要介紹了Web3無助記詞錢包：安全性和便捷度的取舍的相關(guān)資料,需要的朋友可以參考下本文纖細(xì)內(nèi)容介紹…

  2023-05-23
• 

  Web3錢包的未來：創(chuàng)新、挑戰(zhàn)以及重要問題

  這篇文章主要介紹了Web3錢包的未來：創(chuàng)新、挑戰(zhàn)以及重要問題的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-05-19
• 

  Web3中的DAO是什么?Web3和DAO如何改變生產(chǎn)關(guān)系？

  這篇文章主要介紹了Web3中的DAO是什么?Web3和DAO如何改變生產(chǎn)關(guān)系？的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-05-16
• 

  一文分析為什么Web3需要數(shù)字身份?

  這篇文章主要介紹了一文分析為什么Web3需要數(shù)字身份?的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-04-26
• 

  Web3.0時代是一個什么時代?有哪些主要特征?

  這篇文章主要介紹了Web3.0時代是一個什么時代?有哪些主要特征?的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-04-19
• 

  web2與web3有什么區(qū)別?一文了解web2與web3的區(qū)別

  這篇文章主要介紹了web2與web3有什么區(qū)別?一文了解web2與web3的區(qū)別的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-03-29
• 

  Web3睡覺Sleepagotchi 收集NFT還收獲健康睡眠

  這篇文章主要介紹了Web3睡覺Sleepagotchi 收集NFT還收獲健康睡眠的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-03-20
• 

  Web3域名統(tǒng)治者：一文全覽ENS現(xiàn)狀與前景

  正如以太坊在智能合約平臺領(lǐng)域的絕對主導(dǎo)地位，ENS 在 Web3 域名領(lǐng)域的地位也難以被撼動?！?/p> 2023-03-20

• 

  Web3.0的發(fā)展趨勢是什么?2023年Web3.0的五大發(fā)展趨勢

  這篇文章主要介紹了Web3.0的發(fā)展趨勢是什么?2023年Web3.0的五大發(fā)展趨勢的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2023-03-09
• 

  常用web3錢包有哪些軟件?常用web3錢包盤點(diǎn)

  這篇文章主要介紹了常用web3錢包有哪些軟件?常用web3錢包盤點(diǎn)的相關(guān)資料,需要的朋友可以參考下本文詳細(xì)內(nèi)容介紹…

  2026-01-30