En 2005, Jesse James Garrett a écrit un article « Ajax - A New Approach to Web Applications », qui décrivait une application appelée Ajax (Asynchronous JavaScript+XML technology). 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 sur la scène 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 planifiées et les threads de service (service Workers), et est devenue un Web extrêmement puissant. outil de développement.
Une limitation majeure de la communication Ajax via XHR est la politique de sécurité d'origine croisée. 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) définit la manière dont les navigateurs et les serveurs implémentent la communication entre origines. 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ête personnalisé 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 envoyant 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, qui est automatiquement déclenché lors de la tentative d'accès à des ressources d'origines différentes. Pour envoyer une requête à une origine dans un domaine différent, vous pouvez utiliser un objet XHR standard et transmettre une URL absolue à la méthode open(), par exemple :
let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
si(xhr.readyState == 4){
if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
alerte(xhr.reapseText);
}autre{
alert("La demande a échoué :"+xhr.status);
}
}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null); Les objets XHR inter-domaines permettent d'accéder aux propriétés status et statusText, et autoriser également la synchronisation Les demandes qui inter-domaines XHR imposent également des restrictions supplémentaires pour des raisons de sécurité.
Vous ne pouvez pas utiliser setRequestHeader() pour définir des en-têtes personnalisés ;
vous ne pouvez pas envoyer et recevoir de cookies ;
la méthode getAllResponseHeaders() renvoie toujours une chaîne vide
car la même interface est utilisée pour les requêtes du même domaine et entre domaines ; accès aux ressources locales Utilisez des URL relatives et des URL absolues lors de l'accès à des ressources distantes. Cela permet de distinguer plus clairement les scénarios d'utilisation et d'éviter le problème de l'accès restreint aux informations d'en-tête ou de cookie lors de l'accès aux ressources locales.
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 à l'aide de 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) virgule ; -valeurs séparées à utiliser Liste d'en-tête personnalisée ;
L'API Fetch peut effectuer toutes les tâches de l'objet XMLHttpRequest, mais elle est plus facile à utiliser, l'interface est plus moderne et peut être utilisée dans des outils Web tels que Fils de travail Web. 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 d'expédition
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 promesse :
let r = fetch('/bar');console.log(r);//Promise<ending> Format de l'URL (chemin relatif , chemins absolus, etc.) sont interprétés de la même manière que les objets XHR.
Lorsque la requête est terminée et que les ressources sont disponibles, un objet Response sera traité. Cet objet est une encapsulation de l'API grâce à laquelle les ressources correspondantes peuvent être obtenues. Utilisez les propriétés et les méthodes de cet objet pour obtenir des ressources, comprendre la réponse et convertir l'équilibrage de charge en une forme utile.
2. Lisez la réponse. Le moyen le plus simple de lire le contenu de la réponse est d'obtenir le contenu au format texte brut, utilisez simplement la méthode text(). Cette méthode renvoie une promesse, qui consiste à récupérer le contenu complet de la ressource.
3. Gestion des codes d'état et des échecs de requête
L'API Fetch prend en charge la vérification de l'état de la réponse via les propriétés status et statusText de Response. Les requêtes qui obtiennent une réponse produisent généralement un code d'état d'une valeur de 200.
4. Modes de requête de récupération courants :
envoyer des données JSON,
envoyer des paramètres dans le corps de la requête,
envoyer des fichiers
, charger des fichiers Blob
, envoyer des requêtes inter-domaines,
interrompre des requêtes
L'objectif de websocket est d'obtenir un duplex intégral et deux- communication de manière avec le serveur via une connexion à long terme. Lors de la création d'un websocket en JavaScript, une requête HTTP est envoyée au serveur pour initialiser la connexion. Une fois que le serveur a répondu, la connexion passe du protocole HTTP au protocole websocket à l'aide de l'en-tête Upgrade dans HTTP, ce qui signifie que websocket ne peut pas être implémenté via un serveur HTTP standard, mais doit utiliser un serveur propriétaire prenant en charge ce protocole.
Étant donné que websocket utilise un protocole personnalisé, le schéma d'URL a légèrement changé. http:// ou https:// ne peuvent plus être utilisés, mais ws:// et wss:// doivent être utilisés. La première est une connexion non sécurisée et la seconde est une connexion sécurisée. Lors de l'exécution d'URL websocket, le schéma d'URL doit être inclus car il est possible que des schémas supplémentaires soient pris en charge à l'avenir.
L'avantage d'utiliser un protocole personnalisé au lieu du protocole HTTP est que le client et le serveur peuvent envoyer très peu de données sans alourdir HTTP. L'utilisation de paquets de données plus petits rend les websockets idéaux pour les applications mobiles où les problèmes de bande passante et de latence sont importants. L'inconvénient de l'utilisation d'un protocole personnalisé est que la définition du protocole prend plus de temps que la définition de l'API JavaScript, prise en charge par tous les principaux navigateurs.
