一般來講，現在百分之90的開發方式都是前端端分離，通俗來講就是服務端提供一個http的REST API，前端同學去調用服務端的接口進行交互。
因此就衍生出請求代碼的各類封裝，但是網上的開發者從來就沒有一個具體的定義，網上也沒有具體的一個特別規範的一個點。
我個人觀點認爲，封裝就應該是拆分一層又一層，最終目的就是爲了方便維護，方便拓展，方便管理。
傳統的代碼，也是我看見項目最煩的一種代碼：
以上的這種寫法，大體功能是實現了，一眼就覺得新入門的前端同學纔會這樣調用，缺點就是axios沒有任何的封裝，帶來了許多累贅的代碼量，headers每次都需要重複定義，返回結果也是每次都要處理一遍，對於強迫症的前端同學來講，看着就頭疼，我就不一一吐槽了。。。
進階版的代碼：
統一攔截器
post方法封裝
接口調用
以上就是對axios的簡單封裝,主要是從幾個思維，第一就是axios攔截器的綜合應用統一攔截錯誤碼，第二就是post通用方法的封裝方便調用避免了通用參數的調用，這種也是我做開發以來見到各個公司最常見的封裝調用方式，大同小異，基本雷同的思想。
我個人認爲還能再做一層處理，我不認爲這樣封裝請求就算完了，它在項目中依然還有一個弱點，那就是接口不方便管理，各類的接口五花八門。
理想化的調用（本人已投入項目中有使用案例）
理想化的調用就是能把所有的請求url放到一個位置集中歸類並生成，各頁面之間隨用隨調，統一管理所有url，即使後期url改版遷移，你也基本無需更改項目中的代碼，只需要在你封裝的請求方法上簡單的動一動。
api存儲json文件
循環生成接口請求的方法api，這裏直接根據vue的特性，掛載到Vue.prototype上,Vue.prototype.$api = api
（這裏要提一下，關於把接口掛載到vue原型鏈上是否真的可行，有的覺得過多的內容掛載到vue的原型上會讓其根變的笨重，各位可以親測一下，你如果只是把function循環掛載到原型上其實一般是不會影響你網頁的加載速度以及各項性能的。除非你打印出來具體整個對象。實在覺得有問題你也可以無需掛載，直接單個引入，像引入單個組件那樣去使用）
項目中直接調用
以上方法比傳統封裝調用有以下優勢：
- apiName自定義語義化key值，方便自我接口調用
- 解決了後臺定義請求url較長，代碼不美觀問題
- 方便維護接口，假如有項目接口遷移，你只需要在api的json列表去簡單更改
- 接口統一管理，邏輯業務代碼只管調用
以上是對項目封裝請求的一個小結，但是本人太懶，希望這些接口json無需前端手動，而是服務端生成的，前端同學在開發的時候只需要在項目中拉取代碼生成即可，所以有以下構思，也是正準備實踐的，
搭建一個可視化的後臺管理系統，可以配置前端開發中用到的所有接口，把不同項目請求的所需要的json進行統一管理
1.先出原型（產品的活，人人都是產品經理，簡單），在這裏可以新建一個項目，技術選型 nodejs+mysql+redis
*key值和版本就是項目請求json的依據，合併編輯刪除是對項目的操作，合併只能合併同一項目下的不同版本號
2.新建項目可以選擇歷史項目，加上版本號，就參考了git的分支思想，後期迭代時可以不公用一個項目api
3.點擊項目的詳情就是對單個項目的接口管理，在這裏可以新建單個，也可以選擇從公司接口文檔中批量導出
以上是接口管理方案的主流程，只要對外的json開放了http服務，本地項目直接請求通過fs模塊生成到本地目錄即可，出於安全機制考慮會加入賬號系統，日誌管理，並僅部署在內網
以上所有方案均爲個人構思，歡迎各位技術大佬互相學習指正。。。