前端網絡請求的選擇①
目前前端中發送網絡請求的方式有很多種???
選擇一: 傳統的Ajax是基于XMLHttpRequest(XHR)
為什麼不用它呢?
- 非常好解釋, 配置和調用方式等非常混亂.
- 編碼起來看起來就非常蛋疼.
- 是以真實開發中很少直接使用, 而是使用jQuery-Ajax
選擇二: 還有會使用的jQuery-Ajax，相對于傳統的Ajax非常好用.
為什麼不選擇它呢？
- jQuery整個項目太大，單純使用ajax卻要引入整個JQuery非常的不合理（采取個性化打包的方案又不能享受CDN服務）
- 基于原生的XHR開發，XHR本身的架構不清晰，已經有了fetch的替代方案；
- 盡管JQuery對我們前端的開發工作曾有着深遠的影響，但是的确正在推出曆史舞台；
前端網絡請求的選擇②
選擇三: Fetch API
選擇或者不選擇它?
- Fetch是AJAX的替換方案，基于Promise設計，很好的進行了關注分離，有很大一批人喜歡使用fetch進行項目開發；
- 但是Fetch的缺點也很明顯，首先需要明确的是Fetch是一個 low-level（底層）的API，沒有幫助你封裝好各種各樣的功能和實作；
- 比如發送網絡請求需要自己來配置Header的Content-Type，不會預設攜帶cookie等；
- 比如錯誤處理相對麻煩（隻有網絡錯誤才會reject，HTTP狀态碼404或者500不會被标記為reject）；
- 比如不支援取消一個請求，不能檢視一個請求的進度等等；
- MDN Fetch學習位址： 連結 https://developer.mozilla.org/zh-CN/docs/Web/API/Fetch_API/Using_Fetch
選擇四: axios
- axios是目前前端使用非常廣泛的網絡請求庫，包括Vue作者也是推薦在vue中使用axios；
- 主要特點包括：在浏覽器中發送 XMLHttpRequests 請求、在 node.js 中發送 http請求、支援Promise API、攔截請求和響應、轉換請求和響應資料等等；
- axios: ajax i/o system.
Axios的基本使用
支援多種請求方式: axios(config)
- axios.request(config)
- axios.get(url[, config])
- axios.delete(url[, config])
- axios.head(url[, config])
- axios.post(url[, data[, config]])
- axios.put(url[, data[, config]])
- axios.patch(url[, data[, config]])
如何發送請求呢?
大家可以使用這個網站來進行測試時httpbin.org；
axios發送請求
axios發送請求：
- 直接通過axios函數發送請求
- 發送get請求
- 發送post請求
- 多個請求的合并 使用async、await發送請求
axios函數、get、post請求本質上都是request請求
axios的配置資訊
1.請求配置選項
2.響應結構資訊
3.全局預設配置
4.自定義執行個體預設配置：
- 優先是請求的config參數配置；
- 其次是執行個體的default中的配置；
- 最後是建立執行個體時的配置；
axios攔截器
- axios庫有一個非常好用的特性是可以添加攔截器：
- 請求攔截器：在發送請求時，請求被攔截；
- 發送網絡請求時，在頁面中添加一個loading元件作為動畫；
- 某些網絡請求要求使用者必須登入，可以在請求中判斷是否攜帶了token，沒有攜帶token直接跳轉到login頁面；
- 對某些請求參數進行序列化；
- 響應攔截器：在響應結果中，結果被攔截；
- 響應攔截中可以對結果進行二次處理（比如伺服器真正傳回的資料其實是在response的data中）；
- 對于錯誤資訊進行判斷，根據不同的狀态進行不同的處理；
二次封裝
- 為什麼我們要對axios進行二次封裝呢？
- 預設情況下我們是可以直接使用axios來進行開發的；
- 但是我們考慮一個問題，假如有100多處中都直接依賴axios，突然間有一天axios出現了重大bug，并且該庫已經不再維護， 這個時候你如何處理呢？
- 大多數情況下我們會尋找一個新的網絡請求庫或者自己進行二次封裝；
- 但是有100多處都依賴了axios，友善我們進行修改嗎？我們所有依賴axios庫的地方都需要進行修改；
axios二次封裝