Analyse détaillée JavaScript des requêtes réseau et des ressources distantes

Cet article vous apporte des connaissances pertinentes sur javascript Il présente principalement les problèmes liés aux requêtes réseau et aux ressources distantes, notamment le partage de ressources entre origines, les requêtes de contrôle en amont, l'API Fetch, etc. Ce qui suit est Jetons un coup d'œil, j'espère que cela vous aidera. tout le monde.

[Recommandations associées : tutoriel vidéo javascript, front-end web]

1 La naissance d'Ajax

En 2005, Jesse James Garrett a écrit un article "Ajax - Une nouvelle approche des applications Web. " , cet article décrit une technologie appelée Ajax (Asynchronous JavaScript+XML, c'est-à-dire JavaScript+XML asynchrone). Cette technique consiste à envoyer au serveur une demande de données supplémentaires sans actualiser la page, ce qui entraîne une meilleure expérience utilisateur. Garrett explique comment cette technologie modifie le modèle traditionnel « cliquer et attendre » qui persiste depuis la naissance du Web.
La technologie clé qui a poussé Ajax au stade historique est l'objet XMLHttpRequest (XHR). Avant l’avènement de XHR, la communication de type Ajax devait être réalisée grâce à une technologie noire, principalement à l’aide de volets cachés ou de volets en ligne. XHR fournit une interface raisonnable pour envoyer des requêtes au serveur et obtenir des réponses. Cette interface peut obtenir des données supplémentaires du serveur de manière asynchrone, ce qui signifie que les utilisateurs peuvent obtenir des données sans actualiser la page. Après avoir obtenu les données via l'objet XHR, vous pouvez utiliser les méthodes DOM pour insérer les données dans la page Web.
L'API d'objet XHR est généralement considérée comme difficile à utiliser, et l'API Fetch est rapidement devenue une norme alternative plus moderne pour XHR après sa naissance automatique. L'API Fetch prend en charge les promesses futures et les threads de service (service Workers), et est devenue extrêmement puissante. outil de développement web.

2. Partage de ressources multi-origines

Une limitation majeure de la communication Ajax via XHR est la politique de sécurité multi-origine. Par défaut, XHR ne peut accéder qu'aux ressources du même domaine que la page qui a initié la demande. Cette restriction de sécurité empêche certains comportements malveillants. Cependant, les navigateurs doivent également prendre en charge l’accès légal entre origines croisées.
Le partage de ressources cross-origine (CORS, Cross-Origin Resource Sharing) définit la manière dont les navigateurs et les serveurs mettent en œuvre la communication cross-origin. L'idée de base derrière CORS est d'utiliser des en-têtes HTTP personnalisés pour permettre au navigateur et au serveur de se comprendre afin de déterminer si une demande ou une réponse doit réussir ou échouer.
Pour les requêtes simples, telles que les requêtes GET ou POST, il n'y a pas d'en-têtes personnalisés et le corps de la requête est de type texte/plain. Ces requêtes auront un en-tête supplémentaire appelé Origin lors de leur envoi. L'en-tête Origin contient la source (protocole, nom de domaine, port) de la page qui a envoyé la requête afin que le serveur puisse déterminer s'il doit y répondre.
Les navigateurs modernes prennent en charge nativement CORS via l'objet XMLHttpRequst. Ce comportement sera automatiquement déclenché lors de la tentative d'accès à des ressources provenant de différentes sources. Pour envoyer des requêtes à des sources dans différents domaines, vous pouvez utiliser un objet XHR standard et transmettre une URL absolue à la méthode open(), telle que :

let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
	if(xhr.readyState == 4){
		if((xhr.status >= 200 && xhr.status <p>Les objets XHR inter-domaines permettent d'accéder aux propriétés status et statusText, et également autoriser les requêtes synchrones pour des raisons de sécurité. Considérez que les objets XHR inter-domaines imposent également des restrictions supplémentaires. </p>

• ne peut pas utiliser setRequestHeader() pour définir des en-têtes personnalisés ;

• ne peut pas envoyer et recevoir de cookies ;

• getAllResponseHeaders() renvoie toujours une chaîne vide ; ou les requêtes inter-domaines utilisent toutes la même interface, il est donc préférable d'utiliser des URL relatives lors de l'accès aux ressources locales et des URL absolues lors de l'accès aux ressources distantes. Cela permet de distinguer plus clairement les scénarios d'utilisation et d'éviter les en-têtes ou les cookies lors de l'accès aux ressources locales. accès limité à l’information.

3. Requête de contrôle en amont

CORS utilise un mécanisme de vérification du serveur appelé requête de contrôle en amont, permettant l'utilisation d'en-têtes personnalisés, de méthodes autres que GET et POST et de différents types de contenu de corps de requête. Lors de l'envoi d'une requête impliquant l'une des options avancées ci-dessus, une requête de contrôle en amont est d'abord envoyée au serveur. Cette requête est envoyée via la méthode OPTIONS et contient les en-têtes suivants :

Origin : identique à une simple requête

• Access-Control-Request-Method : la méthode que vous souhaitez utiliser ; Access-Control-Request -Headers : (facultatif) Une liste d'en-têtes personnalisés séparés par des virgules à utiliser ;

• IV API Fetch

L'API Fetch peut effectuer toutes les tâches de l'objet XMLHttpRequest, mais est plus facile à utiliser. , possède une interface plus moderne et peut être utilisé dans des outils Web tels que les Web Workers. XMLHttpRequest peut choisir d'être asynchrone, tandis que l'API Fetch doit être asynchrone.
• La méthode fetch() est exposée dans la portée globale, y compris le thread d'exécution de la page principale, les modules et les threads de travail. L’appel de cette méthode amène le navigateur à envoyer une requête à l’URL donnée.

  1. Demande de répartition

  fetch() n'a qu'une seule entrée de paramètre obligatoire. Dans la plupart des cas, ce paramètre est l'URL pour obtenir la ressource, et cette méthode renvoie une date :

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

URL的格式（相对路径、绝对路径等）的解释与XHR对象一样。
请求完成、资源可用时，期约会解决一个Response对象，这个对象是API的封装，可以通过它取得相应资源。获取资源要使用这个对象的属性和方法，掌握响应的情况并将负载均衡转为有用的形式。
2、读取响应
读取响应内容的最简单方式是取得纯文本格式的内容，只要用到text()方法。这个方法返回一个期约，会解决为取得资源的完整内容。
3、处理状态码和请求失败
Fetch API 支持通过Response的status和statusText属性检查响应状态。成功获取响应的请求通常会产生值为200的状态码。
4、常见Fetch请求模式

• 发送JSON数据

• 在请求体中发送参数

• 发送文件

• 加载Blob文件

• 发送跨域请求

• 中断请求

五、websocket

套接字websocket的目标是通过一个长时连接实现与服务器全双工、双向的通信。在JavaScript中创建websocket时，一个HTTP请求会发送到服务器以初始化连接。服务器响应后，连接使用HTTP中的Upgrade头部从HTTP协议切换到websocket协议，这意味着websocket不能通过标准HTTP服务器实现，而必须使用支持该协议的专有服务器。
因为websocket使用了自定义协议，所以URL方案稍有变化，不能再使用http://或https://，而要使用ws://和wss://。前者是不安全的连接，后者是安全连接。在执行websocket URL时，必须包含URL方案，因为将来有可能再支持其他方案。
使用自定义协议而非HTTP协议的好处是，客户端与服务器质检可以发送非常少的数据，不会对HTTP造成任何负担。使用更小的数据包让websocket非常适合宽带和延迟问题比较明显的移动应用。使用自定义协议的缺点是，定义协议的时间比定义JavaScript API的时间要长，websocket得到了所有主流浏览器的支持。

六、JavaScript思维导图

【相关推荐：javascript视频教程、web前端】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!