ajax和axios、fetch的區別

https://www.jianshu.com/p/8bc48f8fde75  區別

 

https://www.jianshu.com/p/7c55f930d363     fetch詳解

ajax和axios、fetch的區別

 

趙客縵胡纓v吳鉤霜雪明 關注

 7.1 2018.09.13 17:57 字數 1116 閱讀 40117評論 8喜歡 177

1.jQuery ajax

$.ajax({
   type: 'POST', url: url, data: data, dataType: dataType, success: function () {}, error: function () {} }); 

傳統 Ajax 指的是 XMLHttpRequest（XHR）， 最先出現的發送後端請求技術，隸屬於原始js中，核心使用XMLHttpRequest對象，多個請求之間若是有前後關係的話，就會出現回調地獄。
JQuery ajax 是對原生XHR的封裝，除此之外還增添了對JSONP的支持。通過多年的更新維護，真的已是很是的方便了，優勢無需多言；若是是硬要舉出幾個缺點，那可能只有：
1.自己是針對MVC的編程,不符合如今前端MVVM的浪潮
2.基於原生的XHR開發，XHR自己的架構不清晰。
3.JQuery整個項目太大，單純使用ajax卻要引入整個JQuery很是的不合理（採起個性化打包的方案又不能享受CDN服務）
4.不符合關注分離（Separation of Concerns）的原則
5.配置和調用方式很是混亂，並且基於事件的異步模型不友好。
PS:MVVM(Model-View-ViewModel), 源自於經典的 Model–View–Controller（MVC）模式。MVVM 的出現促進了 GUI 前端開發與後端業務邏輯的分離，極大地提升了前端開發效率。MVVM 的核心是 ViewModel 層，它就像是一箇中轉站（value converter），負責轉換 Model 中的數據對象來讓數據變得更容易管理和使用，該層向上與視圖層進行雙向數據綁定，向下與 Model 層經過接口請求進行數據交互，起呈上啓下做用。View 層展示的不是 Model 層的數據，而是 ViewModel 的數據，由 ViewModel 負責與 Model 層交互，這就徹底解耦了 View 層和 Model 層，這個解耦是相當重要的，它是先後端分離方案實施的最重要一環。
以下圖所示：

 

image.png

 

2.axios

axios({
    method: 'post', url: '/user/12345', data: { firstName: 'Fred', lastName: 'Flintstone' } }) .then(function (response) { console.log(response); }) .catch(function (error) { console.log(error); }); 

Vue2.0以後，尤雨溪推薦你們用axios替換JQuery ajax，想必讓axios進入了不少人的目光中。
axios 是一個基於Promise 用於瀏覽器和 nodejs 的 HTTP 客戶端，本質上也是對原生XHR的封裝，只不過它是Promise的實現版本，符合最新的ES規範，它自己具備如下特徵：
1.從瀏覽器中建立 XMLHttpRequest
2.支持 Promise API
3.客戶端支持防止CSRF
4.提供了一些併發請求的接口（重要，方便了不少的操做）
5.從 node.js 建立 http 請求
6.攔截請求和響應
7.轉換請求和響應數據
8.取消請求
9.自動轉換JSON數據
PS:防止CSRF:就是讓你的每一個請求都帶一個從cookie中拿到的key, 根據瀏覽器同源策略，假冒的網站是拿不到你cookie中得key的，這樣，後臺就能夠輕鬆辨別出這個請求是不是用戶在假冒網站上的誤導輸入，從而採起正確的策略。
3.fetch

try { let response = await fetch(url); let data = response.json(); console.log(data); } catch(e) { console.log("Oops, error", e); } 

fetch號稱是AJAX的替代品，是在ES6出現的，使用了ES6中的promise對象。Fetch是基於promise設計的。Fetch的代碼結構比起ajax簡單多了，參數有點像jQuery ajax。可是，必定記住fetch不是ajax的進一步封裝，而是原生js，沒有使用XMLHttpRequest對象。
fetch的優勢：
1.符合關注分離，沒有將輸入、輸出和用事件來跟蹤的狀態混雜在一個對象裏
2.更好更方便的寫法
坦白說，上面的理由對我來講徹底沒有什麼說服力，由於不論是Jquery仍是Axios都已經幫咱們把xhr封裝的足夠好，使用起來也足夠方便，爲何咱們還要花費大力氣去學習fetch？
我認爲fetch的優點主要優點就是：

1. 語法簡潔，更加語義化 2. 基於標準 Promise 實現，支持 async/await 3. 同構方便，使用 [isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch) 4.更加底層，提供的API豐富（request, response） 5.脫離了XHR，是ES規範裏新的實現方式 

最近在使用fetch的時候，也遇到了很多的問題：
fetch是一個低層次的API，你能夠把它考慮成原生的XHR，因此使用起來並非那麼舒服，須要進行封裝。
例如：

1）fetch只對網絡請求報錯，對400，500都當作成功的請求，服務器返回 400，500 錯誤碼時並不會 reject，只有網絡錯誤這些致使請求不能完成時，fetch 纔會被 reject。 2）fetch默認不會帶cookie，須要添加配置項： fetch(url, {credentials: 'include'}) 3）fetch不支持abort，不支持超時控制，使用setTimeout及Promise.reject的實現的超時控制並不能阻止請求過程繼續在後臺運行，形成了流量的浪費 4）fetch沒有辦法原生監測請求的進度，而XHR能夠 

總結：axios既提供了併發的封裝，也沒有fetch的各類問題，並且體積也較小，當之無愧如今最應該選用的請求的方式。

 

 

 

fetch詳解部分：

fetch請求出來了一段時間,短暫的在項目中使用過.此次好好學習彙總一下.

第一: fetch的使用
    https://github.com/github/fetch  這個是fetch的github 上面給出了fetch用法.
    https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch 這個是fetch的mdn文檔,更加的詳細.
    查看兩份文檔的時候,github上面沒有設置headers 而在 mdn上有.一開始我也很迷茫,最後我讀到了一句話

 

fetch會自動匹配request 和 response 的content type 

由於fetch 會本身的匹配數據類型設置 content type, 因此發送json 或者formdata 等其餘數據類型的時候,不須要你手動設置.
so intelligently.

 

官方例子

因此在大部分使用的的狀況下,直接使用就行. 和傳統的ajax比起來,fetch 使用起來更加方便,少了繁瑣的配置,又是基於promise,開發者專一於業務就行.
第二: fetch 的缺點
    1.兼容性,fetch的兼容性並不太好,ie 和 safari 都不支持

 

 

fetch 兼容性

在移動端和pc端 兼容性很差由於 返回的reponse body 是readable stream 不支持. 
解決方案: 使用第三方庫 whatwg-fetch, 若是同構在node端使用isomorphic-fetch.

 2.fetch 請求默認不帶cookie
前端請求的時候都會設計到token 權限驗證,不少時候是存在cookie裏面的.fetch裏面又一個參數credentials設計cookie
credentials 有三個值:
                            omit: 默認值，忽略cookie的發送
                            same-origin: 表示cookie只能同域發送，不能跨域發送
                            include: cookie既能夠同域發送，也能夠跨域發送 ( 推薦使用)
推薦使用include.

3.fetch 跨域問題
  fetch跨域也有對應的參數設置mode
                                same-origin：該模式是不容許跨域的，它須要遵照同源策略，不然瀏覽器會返回一個error告知不能跨域；其對應的response type爲basic。
                                cors: 該模式支持跨域請求，顧名思義它是以CORS的形式跨域；固然該模式也能夠同域請求不須要後端額外的CORS支持；其對應的response type爲cors。
                                no-cors: 該模式用於跨域請求可是服務器不帶CORS響應頭，也就是服務端不支持CORS；這也是fetch的特殊跨域請求方式；其對應的response type爲opaque。

4.fetch 返回400 500 問題

 

fetch 返回問題描述

當一個請求發送完成,服務返回狀態碼,fetch 不會reject這個response,仍然resolve,可是 response.ok 會設置成false.不少時候咱們會二次封裝fetch reject error.

 

處理 404 500

5 fetch 沒法 abort 請求 和timeout
目前fetch 沒有傳統ajax 的abort 方法,還在草案之中

 

abort 草案

 

 

abort  解決方案

給fetch內部的promise添加一個abort方法--實際就是reject一個error.

 

timeout 解決方案

使用promise 的race, 由於promise 裏面的resolve 和 reject 只能執行一次, 利用race reject 一個error.
上面的abort 並無真正的abort 這次請求,只是經過promise promise reject 一個error而已.我在翻閱fetch的源碼的時候發現了這個

 

fetch abort

在配置中確實又一個signal 參數能夠abort 請求,發現是基於AbortController,可是這個是一個實驗中屬性,基本不能使用.以上是我對fetch粗淺的總結,有不足的地方歡迎指出.

做者：eveah 連接：https://www.jianshu.com/p/7c55f930d363 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。