[30日でJavaScriptをマスターする〜ネットワーキング]JavaScriptネットワークリクエストとリモートリソース

コンテンツ

まず、Ajaxの誕生

2005年、Jesse James Garrettは、Ajax（Asynchronous JavaScript + XML）と呼ばれるテクノロジーについて説明した記事「Ajax-Webアプリケーションへの新しいアプローチ」を作成しました。この手法では、ページを更新せずにサーバーを送信して追加データを要求するため、ユーザーエクスペリエンスが向上します。ギャレットは、テクノロジーがWebの黎明期から存在していた従来のクリックアンドウェイトモデルをどのように変えるかを説明します。
Ajaxを歴史の段階に導いた主要なテクノロジーは、XMLHttpRequest（XHR）オブジェクトでした。XHRが登場する前は、Ajaxスタイルの通信は、主に非表示のペインまたはインラインのペインを使用して、ハッキーなテクノロジーを介して実現する必要がありました。XHRは、サーバー要求を送信して応答を取得するための合理的なインターフェースを提供します。このインターフェースは、サーバーからの追加データの非同期取得を実現できます。つまり、ユーザーはページを更新せずにデータを取得できます。XHRオブジェクトを介してデータを取得した後、DOMメソッドを使用してデータをWebページに挿入できます。
XHRオブジェクトのAPIは一般的に使いにくいと考えられており、Fetch APIは、自動生成後すぐにXHRの最新の代替標準になりました。FetchAPIは、PromiseとService Workerをサポートし、非常に強力なWeb開発になりました。ツール。。

2.クロスソースリソース共有

XHRを介したAjax通信の主な制限は、クロスオリジンセキュリティポリシーです。デフォルトでは、XHRはリクエストページと同じドメイン内のリソースにのみアクセスできます。このセキュリティ制限は、特定の悪意のある動作を防ぎます。ただし、ブラウザは正当なクロスオリジンアクセス機能もサポートする必要があります。
クロスオリジンリソースシェアリング（CORS、クロスオリジンリソースシェアリング）は、ブラウザーとサーバーがオリジン間で通信する方法を定義します。CORSの背後にある基本的な考え方は、カスタムHTTPヘッダーを使用して、ブラウザーとサーバーが相互に理解し、要求または応答が成功するか失敗するかを判断できるようにすることです。
カスタムヘッダーのないGETまたはPOSTリクエストなどの単純なリクエストの場合、リクエストの本文がtext / plainタイプの場合、そのようなリクエストには、送信時にOriginと呼ばれる追加のヘッダーがあります。Originヘッダーには、リクエストを送信したページのオリジン（プロトコル、ドメイン名、ポート）が含まれているため、サーバーはリクエストを提供するかどうかを判断できます。
最近のブラウザは、XMLHttpRequestオブジェクトを介してCORSをネイティブにサポートしています。このオブジェクトは、さまざまなオリジンからリソースにアクセスしようとすると自動的にトリガーされます。別のドメインのオリジンにリクエストを送信するには、標準のXHRオブジェクトを使用して、絶対URLをopen（）メソッドに渡します。次に例を示します。

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（）を使用してカスタムヘッダーを設定することはできません。
クッキーを送受信できません。
getAllResponseHeaders（）メソッドは常に空の文字列を返します。

同じドメインとクロスドメインの両方のリクエストに同じインターフェースが使用されるため、ローカルリソースにアクセスする場合は相対URLを使用し、リモートリソースにアクセスする場合は絶対URLを使用することをお勧めします。これにより、使用シナリオをより明確に区別し、ローカルリソースへのアクセスを回避できます。リソースが発生したときにヘッダーまたはCookie情報へのアクセスが制限される問題です。

3.事前チェックリクエスト

CORSでは、プリフライトリクエストと呼ばれるサーバー認証メカニズムを通じて、カスタムヘッダー、GETとPOST以外のメソッド、およびさまざまなリクエスト本文のコンテンツタイプを使用できます。上記の高度なオプションのいずれかを含むリクエストを送信する場合、サーバーは最初にプリフライトリクエストを送信します。このリクエストはOPTIONSメソッドを使用して送信され、次のヘッダーが含まれます。

オリジン：単純なリクエストと同じ。
Access-Control-Request-Method：使用するメソッドをリクエストします。
Access-Control-Request-Headers :(オプション）使用するカスタムヘッダーのコンマ区切りリスト。

4.フェッチAPI

Fetch APIは、XMLHttpRequestオブジェクトのすべてのタスクを実行できますが、使いやすく、WebワーカーなどのWebツールで使用できる最新のインターフェイスを備えています。XMLHttpRequestは非同期を選択できますが、FetchAPIは非同期である必要があります。
fetch（）メソッドは、メインページの実行スレッド、モジュール、ワーカースレッドを含むグローバルスコープで公開されます。このメソッドが呼び出されると、ブラウザは指定されたURLにリクエストを送信します。
1.ディスパッチ要求
fetch（）には、必要なパラメーター入力が1つだけあります。ほとんどの場合、このパラメーターはリソースを取得するためのURLであり、このメソッドは予定を返します。

let r = fetch('/bar');
console.log(r);//Promise<pending>

URLの形式（相対パス、絶対パスなど）は、XHRオブジェクトの場合と同じように解釈されます。
リクエストが完了し、リソースが利用可能になると、Responseオブジェクトが解決されることが期待されます。このオブジェクトはAPIのカプセル化であり、対応するリソースを取得できます。リソースを取得するには、このオブジェクトのプロパティとメソッドを使用し、応答を把握して、負荷分散を便利な形式に変えます。
2.応答
を読み取る応答コンテンツを読み取る最も簡単な方法は、text（）メソッドを使用している限り、コンテンツをプレーンテキスト形式で取得することです。このメソッドは、リソースの完全なコンテンツを取得するために解決されるコントラクトを返します。
3.ステータスコードとリクエストの失敗
の処理FetchAPIは、レスポンスのstatusプロパティとstatusTextプロパティによるレスポンスステータスのチェックをサポートしています。応答を取得する要求が成功すると、通常、ステータスコードは200になります。
4.一般的なフェッチ要求モード

JSONデータを送信する
リクエスト本文でパラメータを送信する
ファイル送信
BLOBファイルをロードする
クロスオリジンリクエストを送信する
割り込み要求

5、WebSocket

ソケットWebSocketの目標は、長寿命の接続を介してサーバーとの全二重双方向通信を実現することです。JavaScriptでWebSocketを作成する場合、接続を開始するためにHTTPリクエストがサーバーに送信されます。サーバーが応答した後、接続はHTTPのUpgradeヘッダーを使用してHTTPプロトコルからWebSocketプロトコルに切り替わります。つまり、WebSocketは標準のHTTPサーバーを介して実装できませんが、プロトコルをサポートする専用サーバーを使用する必要があります。
websocketはカスタムプロトコルを使用するため、URLスキームがわずかに変更され、http：//またはhttps：//は使用できなくなりましたが、ws：//およびwss：//を使用してください。前者は安全でない接続であり、後者は安全な接続です。WebSocket URLを実装するときは、他のスキームが将来サポートされる可能性があるため、URLスキームを含める必要があります。
HTTPの代わりにカスタムプロトコルを使用する利点は、クライアントとサーバーのQAがHTTPに負担をかけることなくほとんどデータを送信できないことです。より小さなパケットを使用すると、WebSocketは、帯域幅と遅延の問題が懸念されるモバイルアプリケーションに最適になります。カスタムプロトコルを使用することの欠点は、JavaScript APIよりもプロトコルの定義に時間がかかることです。また、WebSocketはすべての主要なブラウザーでサポートされています。