基于HTTP請求攔截，快速解決跨域和代理Mock

作者：鄧仲哲 2019-03-01 09:55:28

近幾年，隨著 Web 開發(fā)逐漸成熟，前后端分離的架構(gòu)設(shè)計越來越被眾多開發(fā)者認(rèn)可，使得前端和后端可以專注各自的職能，降低溝通成本，提高開發(fā)效率。

在前后端分離的開發(fā)模式下，前端和后端工程師得以并行工作。當(dāng)遇到前端界面展示需要的數(shù)據(jù)，而后端對應(yīng)的接口還沒有完成開發(fā)的情況時，需要一個數(shù)據(jù)源來保證前端工作的順利進行。

今天這篇文章，我們會介紹幾種常見的方法和其中存在的問題，并提出如何基于HTTP 請求攔截，快速解決跨域和代理 mock 問題的方案。

常見方法及問題

請求 mock 服務(wù)器

最常規(guī)的做法是維護一個提供靜態(tài)數(shù)據(jù)的 mock 服務(wù)器(它提供的數(shù)據(jù)稱為 mock 數(shù)據(jù))，前端請求 mock 服務(wù)器獲取數(shù)據(jù)即可，但這種靜態(tài)數(shù)據(jù)維護不便。

請求 AMP

更好的做法是有一個根據(jù)接口定義來自動生成數(shù)據(jù)的 mock 服務(wù)器，我們稱為AMP(接口管理平臺，API Manage Platform)，前端請求該服務(wù)器獲取數(shù)據(jù)。

在這種場景下，如果有些接口已經(jīng)完成開發(fā)，前端需要手動修改代碼去設(shè)置不同接口的請求地址。當(dāng)接口數(shù)量較多時，這種方法會變得非常低效。因此， AMP 一般也會同時提供代理功能，也就是指前端仍請求 AMP，AMP 會根據(jù)接口完成情況來決定返回 mock 數(shù)據(jù)，還是將請求再次代理到真實的業(yè)務(wù)服務(wù)器獲取數(shù)據(jù)后返回。

但是這種方案的問題在于當(dāng)涉及到需要角色權(quán)限驗證的接口時，登錄輸入用戶信息后在瀏覽器中會緩存 cookie，當(dāng)訪問與登錄時同域名的接口時，瀏覽器會自動攜帶 cookie，由服務(wù)器解析 cookie 并鑒權(quán)后獲取對應(yīng)權(quán)限的接口數(shù)據(jù)。前端一般是在本地啟動服務(wù)器進行開發(fā)，當(dāng)業(yè)務(wù)服務(wù)器的接口完成開發(fā)，這時再采用請求 AMP 的方法切換接口數(shù)據(jù)，就會出現(xiàn)跨域的情況。

由于瀏覽器的安全機制決定跨域訪問時無法攜帶 cookie，并且無法通過代碼讀取 cookie，因此通過代碼傳遞 cookie 跨域不可行，而現(xiàn)有的解決方案也不***：

如果在 AMP 額外增加模擬登陸的功能，會因為所有接口的權(quán)限固定不變，無法適配一個接口對不同角色有不同權(quán)限而返回相應(yīng)的數(shù)據(jù);而且一旦鑒權(quán)的接口功能變更、失效等情況發(fā)生，都需要重寫修改 AMP 的代理功能，代價較大。
如果利用瀏覽器插件保存登陸信息、提供代理，則需要兼容不同瀏覽器，成本太高。

針對上述技術(shù)問題，本文提出了一種可跨瀏覽器，并在前端實現(xiàn)的不侵入業(yè)務(wù)代碼的代理方法。

基于 HTTP 請求攔截實現(xiàn)前端接口代理

基于 HTTP 請求攔截實現(xiàn)前端接口的方式，從更底層的角度實現(xiàn)了接口開發(fā)完成前后的 mock 數(shù)據(jù)，及業(yè)務(wù)服務(wù)器真實數(shù)據(jù)之間的切換，并且解決了現(xiàn)有技術(shù)中由 HTTP 請求通過 AMP 代理到業(yè)務(wù)服務(wù)器產(chǎn)生跨域無法攜帶權(quán)限信息，導(dǎo)致無法按照角色權(quán)限返回請求數(shù)據(jù)的技術(shù)問題。

主要創(chuàng)新點

在更底層基于 XMLHttpRequest 和 Fetch API 實現(xiàn)攔截代理，不需要考慮主流瀏覽器類型，和 JavaScript 依賴的工具庫;
在前端實現(xiàn)代理，保留了登陸信息，無需額外處理鑒權(quán)問題;
提供一種可以快速實現(xiàn)且可插拔的使用方式。

總的來說，這個方案提供了一種可快速實現(xiàn)，運行在前端瀏覽器中，且不依賴瀏覽器類型的請求代理方法。

設(shè)計思路

Web 前端開發(fā)一般使用 JavaScript 語言，瀏覽器環(huán)境的 HTTP 請求都是基于 Fetch API 或 XMLHttpRequest API 來實現(xiàn)的(基于前者的請求記做 xhr，后者記做 fetch)，主流的 Javascript 開源工具庫如 Axios、Request 也是這樣。所以，我們的方案就是要通過在底層攔截 xhr 或 fetch，根據(jù)一定的判斷邏輯來實現(xiàn)前端代理功能。

實現(xiàn)方式

首先，重新封裝瀏覽器環(huán)境中原生的 XMLHttpRequest API 和 Fetch API。基本思路是將這兩個原生的 API 保存起來，添加到各自重新封裝的同名 API 中(記作新 API)，為新 API 寫入與原生 API 中同名的方法和屬性，在攜帶請求參數(shù)的同名方法(比如下文中的 open 和 send)里加入攔截請求和代理的邏輯 ApiProxy，對外開放一個可配置該攔截邏輯的接口，用于配置針對不同的 HTTP 請求格式所請求數(shù)據(jù)的攔截和代理邏輯。

圖1：代理與AMP和終端業(yè)務(wù)的交互流程

ApiProxy 在這個過程中的主要作用和工作流程可以歸納為：

注冊攔截器。接收并攔截 HTTP 請求，解析該請求中的參數(shù)，這里的參數(shù)是指能在 AMP 中唯一標(biāo)識該接口的參數(shù)，比如域名+請求方法(如 GET、POST 等)+路徑(如 https://service.com/user 中的/user)。
根據(jù)該參數(shù)生成發(fā)送 AMP 的請求。AMP 實時維護了 mock 服務(wù)器上存儲的接口以及業(yè)務(wù)服務(wù)器上存儲的真實接口的相關(guān)信息，包括接口的定義、域名、屬性、開發(fā)狀態(tài)等。
AMP 根據(jù)請求查詢接口定義數(shù)據(jù)，如果接口存在且狀態(tài)是開發(fā)中，則返回根據(jù)接口定義生成的 mock 數(shù)據(jù)，否則返回特定響應(yīng)標(biāo)志，如圖 1 中的「{code:』200302』}」。
Apiproxy 收到 AMP 的響應(yīng)后判斷是否有特殊標(biāo)志，沒有直接返回 mock 數(shù)據(jù)到原請求，有則表示后端接口開發(fā)完成，繼續(xù)發(fā)送原 HTTP 請求到后端服務(wù)器請求后端服務(wù)器存儲的真實數(shù)據(jù)，相當(dāng)于沒有對原請求做任何處理。

和傳統(tǒng)的將 HTTP 請求發(fā)送給 AMP 不同的是，AMP 根據(jù)接口狀態(tài)判斷是根據(jù)請求直接返回 mock 數(shù)據(jù)，還是開啟代理將 HTTP 請求再發(fā)送給業(yè)務(wù)服務(wù)器(此時跨域訪問會丟失原始 HTTP 請求中瀏覽器攜帶的 cookie)，不直接將 HTTP 請求發(fā)送給 AMP，而是對請求正式發(fā)出之前進行攔截，并解析其中的參數(shù)發(fā)送給 AMP，由 AMP 反饋接口狀態(tài)，若開發(fā)完成則將 HTTP 請求正式發(fā)送給業(yè)務(wù)服務(wù)器。因為沒有修改該請求，只是延遲發(fā)送，這樣就保持了原請求與業(yè)務(wù)服務(wù)器之間的所有鑒權(quán)等相關(guān)信息，由此解決了跨域訪問無法攜帶 cookie 的問題。

不同請求方式下 ApiProxy 的實現(xiàn)

由于不同請求方式的底層設(shè)計不同，我們相應(yīng)的具體封裝手段也不同。

圖2：代理核心工作原理

XMLHttpRequest

對于 XMLHttpRequest 請求，在其 open 方法中解析請求，訪問 AMP 根據(jù)響應(yīng)結(jié)果判斷是否需要繼續(xù)發(fā)送原請求到后臺服務(wù)器，一個 xhr 只有在其 send 方法被調(diào)用時才會真正的發(fā)起 HTTP 請求，而在 open 方法中無法獲取到 send 方法傳遞的數(shù)據(jù)，所以攔截發(fā)生在 send 方法中。首先單獨存儲 send 方法中發(fā)送請求時的參數(shù)，然后直接返回，確保先不調(diào)用真正的 XMLHttpRequest 的 send 方法，將單獨存儲的參數(shù)生成對 AMP 的請求，執(zhí)行上述 AMP 中的判斷。

實例

1、定義與原生 XMLHttpRequest API 同名的接口，稱為新的 XHR 接口;

2、重命名原生 XMLHttpRequest API 并添加到新的 XHR 接口;

3、在新的 XHR 接口中定義與原生 XMLHttpRequest API 同名的屬性和方法;

4、在同名的 open 方法中解析 HTTP 請求，得到用來在 AMP 查詢接口狀態(tài)的參數(shù)(比如域名+請求方法+路徑);

5、攔截將要發(fā)送的原請求，在同名的 send 方法中暫存原請求要發(fā)送的數(shù)據(jù)，暫停原請求的發(fā)送;

6、用 4 中的參數(shù)請求 AMP，查詢接口狀態(tài)，如果接口不存在或是已完成狀態(tài)，則返回特殊標(biāo)志，ApiProxy 取出 5 中暫存的數(shù)據(jù)，傳遞給原請求，并繼續(xù)原請求的發(fā)送;否則，AMP 返回 mock 數(shù)據(jù)，ApiProxy 直接將該數(shù)據(jù)返回給原請求。

Fetch API

對于 Fetch API 而言，因為它是基于 Promise 實現(xiàn)的，攔截比較容易，只需要在 Fetch API 外層封裝一個 Promise 入口，在其發(fā)起 fetch 請求前，先暫停原請求，解析數(shù)據(jù)請求 AMP，并等待響應(yīng)，判斷響應(yīng)是否有特殊響應(yīng)碼，如果有則繼續(xù)原請求，否則跳過原請求，直接返回 mock 數(shù)據(jù)。

啟動前端代理功能

在前端實際開發(fā)中，可以借助打包工具，比如 webpack，自定義一個可配置的插件，開啟后在開發(fā)環(huán)境中自動將代理攔截代碼插入到主頁面里，從而啟動前端代理功能。

小結(jié)

本文提出的前端代理方法通過將代理職責(zé)下沉到前端，減少了 mock 服務(wù)器(或者接口管理平臺)請求真實業(yè)務(wù)服務(wù)器步驟，同時將角色權(quán)限保持在前端請求中，進一步減少了代理所需要承擔(dān)的工作量，從底層攔截 HTTP 請求的方法，繞過了利用瀏覽器插件做代理帶來的瀏覽器兼容的問題。***提供的利用打包工具(如 webpack)封裝這種代理方法，實現(xiàn)快速插拔的前端代理。

本文作者：鄧仲哲，馬蜂窩社區(qū)研發(fā)團隊前端開發(fā)工程師，主要負(fù)責(zé)社區(qū)管理后臺，接口管理平臺開發(fā)等工作。

附：參考資料

關(guān)于跨域:https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

關(guān)于XMLHTTPRequest:https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

關(guān)于Fetch:https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API