建站
咨詢
售后
建站咨詢
新聞中心
今天小編給大家分享一下JavaScript網(wǎng)絡(luò)請求與遠程資源的方法的相關(guān)知識點，內(nèi)容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比紅旗網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式紅旗網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋紅旗地區(qū)。費用合理售后完善，10年實體公司更值得信賴。
一、Ajax的誕生
2005年，Jesse James Garrett撰寫了一篇文章《Ajax - A New Approach to Web Applications》，這篇文章中描繪了一個被稱為Ajax（Asynchronous JavaScript+XML，即異步JavaScript+XML）的技術(shù)。這個技術(shù)涉及發(fā)送服務(wù)器請求額外數(shù)據(jù)而不刷新頁面，從而實現(xiàn)更好地用戶體驗。Garrett解釋了這個技術(shù)怎樣改變自Web誕生以來就一直延續(xù)的傳統(tǒng)單擊等待的模式。
把Ajax推到歷史舞臺上的關(guān)鍵技術(shù)是XMLHttpRequest（XHR）對象。在XHR出現(xiàn)之前，Ajax風(fēng)格的通信必須通過一些黑科技實現(xiàn)，主要是使用隱藏的窗格或內(nèi)嵌窗格。XHR為發(fā)送服務(wù)器請求和獲取相應(yīng)提供了合理的接口。這個接口可以實現(xiàn)異步從服務(wù)器獲取額外數(shù)據(jù)，意味著用戶不用頁面刷新也可以獲取數(shù)據(jù)。通過XHR對象獲取數(shù)據(jù)后，可以使用DOM方法把數(shù)據(jù)插入網(wǎng)頁。
XHR對象的API被普遍認為比較難用，而Fetch API自動誕生以后迅速成為了XHR更現(xiàn)代的替代標(biāo)準(zhǔn)，F(xiàn)etch API支持期約promise和服務(wù)線程（service worker），已經(jīng)成為及其強大的Web開發(fā)工具。
二、跨源資源共享
通過XHR進行Ajax通信的一個主要限制是跨源安全策略。默認情況下，XHR只能訪問與發(fā)起請求的頁面在同一域內(nèi)的資源。這個安全限制可以防止某些惡意行為。不過，瀏覽器也需要支持合法跨源訪問的能力。
跨源資源共享（CORS，Cross-Origin Rerource Sharing）定義了瀏覽器與服務(wù)器如何實現(xiàn)跨源通信。CORS背后的基本思路就是使用自定義的HTTP頭部允許瀏覽器和服務(wù)器相互了解，以確定請求或相應(yīng)應(yīng)該成功還是失敗。
對于簡單的請求，比如GET或POST請求，沒有自定義頭部，而且請求體是text/plain類型，這樣的請求在發(fā)送時會有一個額外的頭部叫Origin。Origin頭部包含發(fā)送請求的頁面的源（協(xié)議、域名、端口），以便服務(wù)器確定是否為其提供響應(yīng)。
現(xiàn)代瀏覽器通過XMLHttpRequst對象原生支持CORS，在嘗試訪問不同源的資源時，這個行為會被自動觸發(fā)。要向不同域的源發(fā)送請求，可以使用標(biāo)準(zhǔn)XHR對象并給open()方法傳入一個絕對URL，比如：
let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
alert(xhr.reaponseText);
}else{
alert("Request was unsuccessful:"+xhr.status);
}
}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null);跨域XHR對象允許訪問status和statusText屬性，也允許同步請求，出于安全考慮，跨域XHR對象也施加了一些額外的限制。
不能使用setRequestHeader()設(shè)置自定義頭部；
不能發(fā)送和接收cookie；
getAllResponseHeaders()方法始終返回空字符串；
因為無論同域還是跨域請求都是用同一個接口，所以最好在訪問本地資源時使用相對URL，在訪問遠程資源時使用絕對URL，這樣可以更明確地區(qū)分使用場景，同時避免出現(xiàn)訪問本地資源時出現(xiàn)頭部或cookie信息訪問受限的問題。
三、預(yù)檢請求
CORS通過一種叫預(yù)檢請求的服務(wù)器驗證機制，允許使用自定義頭部、除GET和POST之外的方法，以及不同請求體內(nèi)容類型。在要發(fā)送涉及上述某種高級選項的請求時，會先想服務(wù)器發(fā)送一個預(yù)檢請求。這個請求使用OPTIONS方法發(fā)送并包含如下頭部：
Origin：與簡單請求相同；
Access-Control-Request-Method：請求希望使用的方法；
Access-Control-Request-Headers：（可選）要使用的逗號分隔的自定義頭部列表；
四、Fetch API
Fetch API能夠執(zhí)行XMLHttpRequest對象的所有任務(wù)，但更容易使用，接口也更現(xiàn)代化，能夠在Web工作線程等Web工具中使用。XMLHttpRequest可以選擇異步，而Fetch API則必須是異步。
fetch()方法是暴露在全局作用域中的，包括主頁面執(zhí)行線程、模塊和工作線程。調(diào)用這個方法，瀏覽器就會向給定URL發(fā)送請求。
1、分派請求
fetch()只有一個必需的參數(shù)input。多數(shù)情況下，這個參數(shù)是獲取資源的URL，這個方法返回一個期約：
let r = fetch('/bar');console.log(r);//PromiseURL的格式（相對路徑、絕對路徑等）的解釋與XHR對象一樣。
請求完成、資源可用時，期約會解決一個Response對象，這個對象是API的封裝，可以通過它取得相應(yīng)資源。獲取資源要使用這個對象的屬性和方法，掌握響應(yīng)的情況并將負載均衡轉(zhuǎn)為有用的形式。
2、讀取響應(yīng)
讀取響應(yīng)內(nèi)容的最簡單方式是取得純文本格式的內(nèi)容，只要用到text()方法。這個方法返回一個期約，會解決為取得資源的完整內(nèi)容。
3、處理狀態(tài)碼和請求失敗
Fetch API 支持通過Response的status和statusText屬性檢查響應(yīng)狀態(tài)。成功獲取響應(yīng)的請求通常會產(chǎn)生值為200的狀態(tài)碼。
4、常見Fetch請求模式
發(fā)送JSON數(shù)據(jù)
在請求體中發(fā)送參數(shù)
發(fā)送文件
加載Blob文件
發(fā)送跨域請求
中斷請求
五、websocket
套接字websocket的目標(biāo)是通過一個長時連接實現(xiàn)與服務(wù)器全雙工、雙向的通信。在JavaScript中創(chuàng)建websocket時，一個HTTP請求會發(fā)送到服務(wù)器以初始化連接。服務(wù)器響應(yīng)后，連接使用HTTP中的Upgrade頭部從HTTP協(xié)議切換到websocket協(xié)議，這意味著websocket不能通過標(biāo)準(zhǔn)HTTP服務(wù)器實現(xiàn)，而必須使用支持該協(xié)議的專有服務(wù)器。
因為websocket使用了自定義協(xié)議，所以URL方案稍有變化，不能再使用http://或https://，而要使用ws://和wss://。前者是不安全的連接，后者是安全連接。在執(zhí)行websocket URL時，必須包含URL方案，因為將來有可能再支持其他方案。
使用自定義協(xié)議而非HTTP協(xié)議的好處是，客戶端與服務(wù)器質(zhì)檢可以發(fā)送非常少的數(shù)據(jù)，不會對HTTP造成任何負擔(dān)。使用更小的數(shù)據(jù)包讓websocket非常適合寬帶和延遲問題比較明顯的移動應(yīng)用。使用自定義協(xié)議的缺點是，定義協(xié)議的時間比定義JavaScript API的時間要長，websocket得到了所有主流瀏覽器的支持。
以上就是“JavaScript網(wǎng)絡(luò)請求與遠程資源的方法”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學(xué)習(xí)更多的知識，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
網(wǎng)頁題目：JavaScript網(wǎng)絡(luò)請求與遠程資源的方法
網(wǎng)頁URL：http://biofuelwatch.net/article/pcoiei.html
