摘要:我們都知道因為同源策略的問題,瀏覽器的請求是可能隨便跨域的一定要有跨域頭或者借助,但是,中可以設置為不跨域,如下所示這樣之后我們會得到一個為的返回。
免費幫忙內推阿里等各大IT公司的崗位,有興趣可以帶簡歷加微信angeltune引言
前端技術真是一個發展飛快的領域,我三年前入職的時候只有原生XHR和Jquery ajax,我們還曾被JQuery 1.9版本版本以下不支持大文件請求這個問題卡了半天(最后自己寫了原生的XHR請求)。一晃眼,JQuery ajax早已不能專美于前,axios和fetch都已經開始分別搶占“請求”這個前端高地。本文將會嘗試著闡述他們之間的區別,并給出自己的一些理解。
1 JQuery ajax$.ajax({ type: "POST", url: url, data: data, dataType: dataType, success: function () {}, error: function () {} });
這個我就不用多言了把,是對原生XHR的封裝,除此以外還增添了對JSONP的支持。有一說一的說一句,JQuery ajax經過多年的更新維護,真的已經是非常的方便了,優點無需多言;如果是硬要舉出幾個缺點,那可能只有
本身是針對MVC的編程,不符合現在前端MVVM的浪潮
基于原生的XHR開發,XHR本身的架構不清晰,已經有了fetch的替代方案
JQuery整個項目太大,單純使用ajax卻要引入整個JQuery非常的不合理(采取個性化打包的方案又不能享受CDN服務)
盡管JQuery對我們前端的開發工作曾有著(現在也仍然有著)深遠的影響,但是我們可以看到隨著VUE,REACT新一代框架的興起,以及ES規范的完善,更多API的更新,JQuery這種大而全的JS庫,未來的路會越走越窄。
總結:廉頗老矣,尚能飯,但是總有飯不動的一天。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本質上也是對原生XHR的封裝,只不過它是Promise的實現版本,符合最新的ES規范,從它的官網上可以看到它有以下幾條特性:
從 node.js 創建 http 請求
支持 Promise API
客戶端支持防止CSRF
提供了一些并發請求的接口(重要,方便了很多的操作)
這個支持防止CSRF其實挺好玩的,是怎么做到的呢,就是讓你的每個請求都帶一個從cookie中拿到的key, 根據瀏覽器同源策略,假冒的網站是拿不到你cookie中得key的,這樣,后臺就可以輕松辨別出這個請求是否是用戶在假冒網站上的誤導輸入,從而采取正確的策略。
Axios既提供了并發的封裝,也沒有下文會提到的fetch的各種問題,而且體積也較小,當之無愧現在最應該選用的請求的方式。
總結:誰敢橫刀立馬,唯我Axios將軍!3 Fetch
fetch號稱是AJAX的替代品,它的好處在《傳統 Ajax 已死,Fetch 永生》中提到有以下幾點:
符合關注分離,沒有將輸入、輸出和用事件來跟蹤的狀態混雜在一個對象里
更好更方便的寫法,諸如:
try { let response = await fetch(url); let data = response.json(); console.log(data); } catch(e) { console.log("Oops, error", e); }
坦白說,上面的理由對我來說完全沒有什么說服力,因為不管是Jquery還是Axios都已經幫我們把xhr封裝的足夠好,使用起來也足夠方便,為什么我們還要花費大力氣去學習fetch?
我認為fetch的優勢主要優勢就是:
更加底層,提供的API豐富(request, response)
脫離了XHR,是ES規范里新的實現方式
大家都喜歡新的東西,坦白說,作為一個前端工程師,我在使用原生XHR的時候,盡管偶爾覺得寫的丑陋,但是在使用了JQuery和axios之后,已經對這一塊完全無所謂了。當然,如果新的fetch能做的同樣好,我為了不掉隊也會選擇使用fetch。這個道理其實很好理解:你有一架殲8,魔改了N次,性能達到了殲10的水準,但是要是有個人給你拿來一架新的殲10,你也會毫不猶豫的選擇新的殲10——不僅僅是新,也代表了還有新的魔改潛力。
但是我最近在使用fetch的時候,也遇到了不少的問題:
fetch是一個低層次的API,你可以把它考慮成原生的XHR,所以使用起來并不是那么舒服,需要進行封裝
例如:
1)fetch只對網絡請求報錯,對400,500都當做成功的請求,需要封裝去處理
2)fetch默認不會帶cookie,需要添加配置項
3)fetch不支持abort,不支持超時控制,使用setTimeout及Promise.reject的實現的超時控制并不能阻止請求過程繼續在后臺運行,造成了流量的浪費
4)fetch沒有辦法原生監測請求的進度,而XHR可以
PS: fetch的具體問題大家可以參考:《fetch沒有你想象的那么美》《fetch使用的常見問題及解決方法》
看到這里,你心里一定有個疑問,這鬼東西就是個半拉子工程嘛,我還是回去用Jquery或者Axios算了——其實我就是這么打算的。但是,必須要提出的是,我發現fetch在前端的應用上有一項xhr怎么也比不上的能力:跨域的處理。
我們都知道因為同源策略的問題,瀏覽器的請求是可能隨便跨域的——一定要有跨域頭或者借助JSONP,但是,fetch中可以設置mode為"no-cors"(不跨域),如下所示:
fetch("/users.json", { method: "post", mode: "no-cors", data: {} }).then(function() { /* handle response */ });
這樣之后我們會得到一個type為“opaque”的返回。需要指出的是,這個請求是真正抵達過后臺的,所以我們可以使用這種方法來進行信息上報,在我們之前的image.src方法中多出了一種選擇,另外,我們在network中可以看到這個請求后臺設置跨域頭之后的實際返回,有助于我們提前調試接口(當然,通過chrome插件我們也可以做的到)。總之,fetch現在還不是很好用,我嘗試過幾個fetch封裝的包,都還不盡如人意。
總結:酋長的孩子,還需成長總結
如果你是直接拉到文章底部的,只需要知道現在無腦使用axios即可,Jquery老邁笨拙,fetch年輕稚嫩,只有Axios正當其年!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/92488.html
摘要:是在收到響應后執行的函數,可以不用返回。一步步介紹了如何構建以及使用中間層,來統一管理接口地址,最后還介紹了下中間件等高級功能。 零、問題的由來 開門見山地說,這篇文章是一篇安利軟文~,安利的對象就是最近搞的 tua-api。 顧名思義,這就是一款輔助獲取接口數據的工具。 發請求相關的工具辣么多,那我為啥要用你呢? 理想狀態下,項目中應該有一個 api 中間層。各種接口在這里定義,業務...
摘要:因為頁面通過加載的初始請求是安全的,但是又加載了不安全的內容,因此稱之為混合內容。但是即使顯示警告,頁面也已經加載,用戶的安全仍然受到了威脅。這就是頁面為什么發送不了的原因。 我們都知道HTTPS的頁面是發送不了HTTP請求的,那么是什么原因導致HTTPS頁面不能發送HTTP請求呢?如果有發送的需求,怎么樣才能發送?最近剛好遇到了這個問題,而且搜了半天沒搜到靠譜的答案,所以有了本文。 ...
摘要:相對于工廠模式,抽象工廠模式生產的對象更加具體,也更加豐富,但相對編碼也更加復雜。具體的抽象工廠模式的實現大家可以參考菜鳥教程。知道了工廠模式和抽象工廠模式的區別,請大家使用的時候應該根據具體的情況進行選擇。 大家好,今天給大家分享一些Spring的學習心得,在講Spring之前,先和大家分享Spring中核心的設計模式。 工廠模式 在聊概念之前我先問問大家:什么是工廠? 這個很簡單,...
摘要:所以本文將介紹兩個目前常用的獲取服務器數據的庫和。隨著作者尤雨溪發布消息,不再繼續維護并推薦大家使用開始,進入了很多人的目光。脫離了,是基于設計。如果要詳細了解的應用,推薦閱讀教程和規范。歡迎大家前往騰訊云+社區,獲取更多騰訊海量技術實踐干貨哦~ 本文由前端林子發表于云+社區專欄 隨著前端技術的發展,請求服務器數據的方法早已不局限于ajax、jQuery的ajax方法。各種js庫已如雨后...
閱讀 1104·2021-11-16 11:45
閱讀 3124·2021-10-13 09:40
閱讀 714·2019-08-26 13:45
閱讀 1188·2019-08-26 13:32
閱讀 2167·2019-08-26 13:23
閱讀 911·2019-08-26 12:16
閱讀 2823·2019-08-26 11:37
閱讀 1748·2019-08-26 10:32