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

馬蜂窩技術發表於2019-03-12

HTTP跨域Mock

近幾年，隨著 Web 開發逐漸成熟，前後端分離的架構設計越來越被眾多開發者認可，使得前端和後端可以專注各自的職能，降低溝通成本，提高開發效率。

在前後端分離的開發模式下，前端和後端工程師得以並行工作。當遇到前端介面展示需要的資料，而後端對應的介面還沒有完成開發的情況時，需要一個資料來源來保證前端工作的順利進行。

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

常見方法及問題

請求 mock 伺服器

最常規的做法是維護一個提供靜態資料的 mock 伺服器（它提供的資料稱為 mock 資料），前端請求 mock 伺服器獲取資料即可，但這種靜態資料維護不便。

請求 AMP

更好的做法是有一個根據介面定義來自動生成資料的 mock 伺服器，我們稱為AMP（介面管理平臺，API Manage Platform），前端請求該伺服器獲取資料。

在這種場景下，如果有些介面已經完成開發，前端需要手動修改程式碼去設定不同介面的請求地址。當介面數量較多時，這種方法會變得非常低效。因此， AMP 一般也會同時提供代理功能，也就是指前端仍請求 AMP，AMP 會根據介面完成情況來決定返回 mock 資料，還是將請求再次代理到真實的業務伺服器獲取資料後返回。

但是這種方案的問題在於當涉及到需要角色許可權驗證的介面時，登入輸入使用者資訊後在瀏覽器中會快取 cookie，當訪問與登入時同域名的介面時，瀏覽器會自動攜帶 cookie，由伺服器解析 cookie 並鑑權後獲取對應許可權的介面資料。前端一般是在本地啟動伺服器進行開發，當業務伺服器的介面完成開發，這時再採用請求 AMP 的方法切換介面資料，就會出現跨域的情況。

由於瀏覽器的安全機制決定跨域訪問時無法攜帶 cookie，並且無法通過程式碼讀取 cookie，因此通過程式碼傳遞 cookie 跨域不可行，而現有的解決方案也不完美：

如果在 AMP 額外增加模擬登陸的功能，會因為所有介面的許可權固定不變，無法適配一個介面對不同角色有不同許可權而返回相應的資料；而且一旦鑑權的介面功能變更、失效等情況發生，都需要重寫修改 AMP 的代理功能，代價較大。
如果利用瀏覽器外掛儲存登陸資訊、提供代理，則需要相容不同瀏覽器，成本太高。

針對上述技術問題，本文提出了一種可跨瀏覽器，並在前端實現的不侵入業務程式碼的代理方法。

基於 HTTP 請求攔截

實現前端介面代理

基於 HTTP 請求攔截實現前端介面的方式，從更底層的角度實現了介面開發完成前後的 mock 資料，及業務伺服器真實資料之間的切換，並且解決了現有技術中由 HTTP 請求通過 AMP 代理到業務伺服器產生跨域無法攜帶許可權資訊，導致無法按照角色許可權返回請求資料的技術問題。

主要創新點

在更底層基於 XMLHttpRequest 和 Fetch API 實現攔截代理，不需要考慮主流瀏覽器型別，和 JavaScript 依賴的工具庫；
在前端實現代理，保留了登陸資訊，無需額外處理鑑權問題；
提供一種可以快速實現且可插拔的使用方式。

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

設計思路

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

實現方式

首先，重新封裝瀏覽器環境中原生的 XMLHttpRequest API 和 Fetch API。基本思路是將這兩個原生的 API 儲存起來，新增到各自重新封裝的同名 API 中（記作新 API），為新 API 寫入與原生 API 中同名的方法和屬性，在攜帶請求引數的同名方法（比如下文中的 open 和 send）里加入攔截請求和代理的邏輯 ApiProxy，對外開放一個可配置該攔截邏輯的介面，用於配置針對不同的 HTTP 請求格式所請求資料的攔截和代理邏輯。

圖1：代理與AMP和終端業務的互動流程

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

註冊攔截器。接收並攔截 HTTP 請求，解析該請求中的引數，這裡的引數是指能在 AMP 中唯一標識該介面的引數，比如域名+請求方法（如 GET、POST 等）+路徑（如 https://service.com/user 中的/user）。
根據該引數生成傳送 AMP 的請求。AMP 實時維護了 mock 伺服器上儲存的介面以及業務伺服器上儲存的真實介面的相關資訊，包括介面的定義、域名、屬性、開發狀態等。
AMP 根據請求查詢介面定義資料，如果介面存在且狀態是開發中，則返回根據介面定義生成的 mock 資料，否則返回特定響應標誌，如圖 1 中的「{code:』200302』}」。
Apiproxy 收到 AMP 的響應後判斷是否有特殊標誌，沒有直接返回 mock 資料到原請求，有則表示後端介面開發完成，繼續傳送原 HTTP 請求到後端伺服器請求後端伺服器儲存的真實資料，相當於沒有對原請求做任何處理。

和傳統的將 HTTP 請求傳送給 AMP 不同的是，AMP 根據介面狀態判斷是根據請求直接返回 mock 資料，還是開啟代理將 HTTP 請求再傳送給業務伺服器（此時跨域訪問會丟失原始 HTTP 請求中瀏覽器攜帶的 cookie），不直接將 HTTP 請求傳送給 AMP，而是對請求正式發出之前進行攔截，並解析其中的引數傳送給 AMP，由 AMP 反饋介面狀態，若開發完成則將 HTTP 請求正式傳送給業務伺服器。因為沒有修改該請求，只是延遲傳送，這樣就保持了原請求與業務伺服器之間的所有鑑權等相關資訊，由此解決了跨域訪問無法攜帶 cookie 的問題。

不同請求方式下 ApiProxy 的實現

由於不同請求方式的底層設計不同，我們相應的具體封裝手段也不同。

圖2：代理核心工作原理

XMLHttpRequest

對於 XMLHttpRequest 請求，在其 open 方法中解析請求，訪問 AMP 根據響應結果判斷是否需要繼續傳送原請求到後臺伺服器，一個 xhr 只有在其 send 方法被呼叫時才會真正的發起 HTTP 請求，而在 open 方法中無法獲取到 send 方法傳遞的資料，所以攔截髮生在 send 方法中。首先單獨儲存 send 方法中傳送請求時的引數，然後直接返回，確保先不呼叫真正的 XMLHttpRequest 的 send 方法，將單獨儲存的引數生成對 AMP 的請求，執行上述 AMP 中的判斷。

例項

1、定義與原生 XMLHttpRequest API 同名的介面，稱為新的 XHR 介面；

2、重新命名原生 XMLHttpRequest API 並新增到新的 XHR 介面；

3、在新的 XHR 介面中定義與原生 XMLHttpRequest API 同名的屬性和方法；

4、在同名的 open 方法中解析 HTTP 請求，得到用來在 AMP 查詢介面狀態的引數（比如域名+請求方法+路徑）；

5、攔截將要傳送的原請求，在同名的 send 方法中暫存原請求要傳送的資料，暫停原請求的傳送；

6、用 4 中的引數請求 AMP，查詢介面狀態，如果介面不存在或是已完成狀態，則返回特殊標誌，ApiProxy 取出 5 中暫存的資料，傳遞給原請求，並繼續原請求的傳送；否則，AMP 返回 mock 資料，ApiProxy 直接將該資料返回給原請求。

Fetch API

對於 Fetch API 而言，因為它是基於 Promise 實現的，攔截比較容易，只需要在 Fetch API 外層封裝一個 Promise 入口，在其發起 fetch 請求前，先暫停原請求，解析資料請求 AMP，並等待響應，判斷響應是否有特殊響應碼，如果有則繼續原請求，否則跳過原請求，直接返回 mock 資料。

啟動前端代理功能

在前端實際開發中，可以藉助打包工具，比如 webpack，自定義一個可配置的外掛，開啟後在開發環境中自動將代理攔截程式碼插入到主頁面裡，從而啟動前端代理功能。

小結

本文提出的前端代理方法通過將代理職責下沉到前端，減少了 mock 伺服器（或者介面管理平臺）請求真實業務伺服器步驟，同時將角色許可權保持在前端請求中，進一步減少了代理所需要承擔的工作量，從底層攔截 HTTP 請求的方法，繞過了利用瀏覽器外掛做代理帶來的瀏覽器相容的問題。最後提供的利用打包工具（如 webpack）封裝這種代理方法，實現快速插拔的前端代理。

本文作者奴止，馬蜂窩社群研發團隊前端開發工程師，主要負責社群管理後臺，介面管理平臺開發等工作。

關注馬蜂窩技術，找到更多你需要的內容

附：參考資料

關於跨域:

developer.mozilla.org/en-US/docs/…

關於XMLHTTPRequest: