Maison >interface Web >js tutoriel >XmlHttpRequest vs l'API Fetch pour ajax

XmlHttpRequest vs l'API Fetch pour ajax

Christopher Nolan
Christopher Nolanoriginal
2025-02-14 09:33:12664parcourir

XMLHttpRequest vs the Fetch API for Ajax

Points de base

  • Dans JavaScript, l'API Fetch et XMLHTTPRequest sont utilisées pour faire des demandes HTTP, mais l'API Fetch est généralement considérée comme plus puissante et flexible car elle utilise la promesse, ce qui simplifie le code et la gestion des erreurs. Cependant, tous les navigateurs ne prennent pas en charge l'API Fetch, en particulier les navigateurs plus anciens.
  • xmlhttprequest Bien que plus ancien et plus complexe en raison du manque de promesse, il est largement pris en charge dans tous les navigateurs et envoie des cookies par défaut, ce qui est utile pour les demandes de serveur qui nécessitent des cookies pour s'authentifier.
  • API Fetch n'est pas un remplacement complet de la technologie Ajax, car il ne prend pas en charge toutes les fonctionnalités XHR et certaines options peuvent être lourdes. Il ne soutient pas non plus les délais d'attente, ce qui rend la mise en œuvre de la capture d'erreur plus complexe.
  • Bien que l'API Fetch ait ses limites, c'est l'orientation future pour faire des demandes HTTP en JavaScript. Cependant, en raison de son relativement nouveau et en constante évolution, les développeurs devraient l'utiliser avec prudence dans les années à venir.

Comparaison des compromis entre XMLHttpRequest et API Fetch

Cet article comparera les avantages et les inconvénients de XMLHttpRequest et sa mise en œuvre moderne AJAX de l'API Fetch. Mars 2019 marque le 20e anniversaire de l'Ajax (dans une certaine mesure). La première implémentation de XMLHTTPRequest a été publiée en 1999 en tant que composant ActiveX pour IE5.0 (ne demandez pas). Avant cela, il y avait également des moyens d'extraire des données du serveur sans actualiser une page pleine page, mais ils comptent souvent sur des techniques maladroites telles que l'injection ou les plugins tiers. Le but principal de Microsoft de développer XMLHTTPRequest est de fournir une alternative à son client Outlook Mail basé sur un navigateur.

xmlhttprequest n'était pas la norme Web avant 2006, mais elle a été implémentée dans la plupart des navigateurs. Son adoption dans Gmail (2004) et Google Maps (2005) a conduit à l'article de Jesse James Garrett "Ajax: une nouvelle approche des applications Web" en 2005. Ce nouveau terme rend les développeurs plus ciblés.

d'Ajax à Ajax

ajax est l'abréviation de JavaScript asynchrone et XML. "Async" est définitivement correct, mais:

  1. Probablement JavaScript, bien que VBScript et Flash soient également facultatifs.
  2. La charge utile n'a pas besoin d'être XML, bien que XML soit très populaire à l'époque. Tout format de données peut être utilisé et de nos jours, JSON est généralement préféré.

Nous utilisons désormais "AJAX" comme terme général pour tout processus client qui fait généralement référence à tout processus client qui obtient des données du serveur et met dynamiquement le DOM sans avoir à effectuer une actualisation pleine page. AJAX est la technologie de base de la plupart des applications Web et des applications à page unique (SPAS).

compréhension approfondie de XmlHttpRequest

Le code JavaScript suivant montre l'utilisation de xmlhttprequest (généralement abrégé sous le nom de xhr) pour émettre une demande de base http pour https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c :

<code class="language-javascript">let xhr = new XMLHttpRequest();
xhr.open('GET', 'https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c');

// 请求状态更改事件
xhr.onreadystatechange = function() {

  // 请求完成?
  if (xhr.readyState !== 4) return;

  if (xhr.status === 200) {
    // 请求成功 - 显示响应
    console.log(xhr.responseText);
  }
  else {
    // 请求错误
    console.log('HTTP error', xhr.status, xhr.statusText);
  }
};

// 开始请求
xhr.send();</code>

L'objet XMLHttpRequest a de nombreuses autres options, événements et propriétés de réponse. Par exemple, les délais d'attente en millisecondes peuvent être définis et détectés:

<code class="language-javascript">// 设置超时
xhr.timeout = 3000; // 3 秒
xhr.ontimeout = () => console.log('timeout', xhr.responseURL);</code>

Les événements de progrès peuvent signaler les téléchargements de fichiers à long terme:

<code class="language-javascript">// 上传进度
xhr.upload.onprogress = p => {
  console.log( Math.round((p.loaded / p.total) * 100) + '%') ;
};</code>
Le nombre d'options dans

peut être éblouissant, et il y a des incohérences entre les navigateurs dans les versions antérieures de XMLHttpRequest. Par conséquent, la plupart des bibliothèques et des frameworks fournissent des fonctions de wrapper ajax pour gérer la complexité, comme la méthode jQuery.ajax ():

<code class="language-javascript">// jQuery Ajax
$.ajax('https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c')
  .done(data => console.log(data))
  .fail((xhr, status) => console.log('error:', status));</code>

Apprenez rapidement sur Fetch

API Fetch est une alternative moderne à xmlhttprequest. Les en-têtes, les interfaces de demande et de réponse courantes fournissent une cohérence, tandis que la promesse permet un chaînage plus facile et asynchrone / attendre sans rappel. L'exemple XHR ci-dessus peut être converti en code basé sur Fetch plus simple, qui peut même analyser le JSON renvoyé:

<code class="language-javascript">fetch(
    'https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c',
    { method: 'GET' }
  )
  .then( response => response.json() )
  .then( json => console.log(json) )
  .catch( error => console.error('error:', error) );</code>

Fetch est simple, élégant, facile à comprendre et largement utilisé chez les travailleurs de services PWA. Pourquoi ne pas l'utiliser au lieu de l'ancien XMLHTTPREQUEST?

Malheureusement, le développement Web n'est jamais aussi simple. Fetch n'a pas complètement remplacé la technologie Ajax ...

Prise en charge du navigateur

API Fetch est assez bien pris en charge, mais échoue dans toutes les versions d'Internet Explorer. Les utilisateurs utilisant des versions Chrome, Firefox et Safari avant 2017 peuvent également rencontrer des problèmes. Ces utilisateurs ne peuvent constituer qu'une petite partie de votre base d'utilisateurs… ou il peut s'agir d'un client majeur. Assurez-vous de vérifier avant de commencer le codage!

De plus, l'API Fetch est relativement nouvelle et reçoit des changements plus continus que les objets XHR matures. Il est peu probable que ces mises à jour brisent le code, mais une certaine maintenance devrait être nécessaire dans les années à venir.

Les cookies ne sont pas inclus par défaut

Contrairement à XMLHTTPREQUEST, toutes les implémentations de récupération n'envoient pas des cookies, de sorte que l'authentification de votre application peut échouer. Ce problème peut être résolu en modifiant les options d'initialisation passées dans le deuxième paramètre, par exemple:

<code class="language-javascript">fetch(
    'https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c',
    {
      method: 'GET',
      credentials: 'same-origin'
    }
  )</code>

Les erreurs ne seront pas rejetées

Étonnamment, les erreurs HTTP (telles que 404 pages introuvables ou 500 erreurs de serveur interne) ne provoquent pas la promesse de fetch à refuser; .catch () ne s'exécute jamais. Il analyse et définit généralement le statut de réponse.

La remise ne se produit que si la demande ne peut pas être terminée (comme une défaillance du réseau). Cela rendra la mise en œuvre de la capture d'erreur plus complexe.

Le délai d'expiration n'est pas pris en charge

Fetch ne prend pas en charge les délais d'attente et la demande durera l'heure sélectionnée du navigateur. Un code supplémentaire est nécessaire pour envelopper la récupération dans une autre promesse, par exemple:

<code class="language-javascript">// 带有超时的 fetch
function fetchTimeout(url, init, timeout = 3000) {
  return new Promise((resolve, reject) => {
    fetch(url, init)
      .then(resolve)
      .catch(reject);
    setTimeout(reject, timeout);
  });
}</code>

… ou peut-être utiliser promesse.race (), qui analyse lorsque la récupération ou le délai est terminé en premier, par exemple:

<code class="language-javascript">Promise.race([
  fetch('http://url', { method: 'GET' }),
  new Promise(resolve => setTimeout(resolve, 3000))
])
  .then(response => console.log(response))</code>

Abortez la récupération

Les demandes

XHR peuvent être facilement terminées à l'aide de Xhr.Abort () et, si nécessaire, la fonction XHR.onabort peut être utilisée pour détecter ces événements.

Pendant des années, abandonner la récupération était impossible, mais il est maintenant pris en charge dans les navigateurs qui implémentent l'API AbortController. Cela déclenche un signal qui peut être transmis à l'objet d'initialisation de récupération:

<code class="language-javascript">let xhr = new XMLHttpRequest();
xhr.open('GET', 'https://www.php.cn/link/f589a241141007eb225cd68eed7bc06c');

// 请求状态更改事件
xhr.onreadystatechange = function() {

  // 请求完成?
  if (xhr.readyState !== 4) return;

  if (xhr.status === 200) {
    // 请求成功 - 显示响应
    console.log(xhr.responseText);
  }
  else {
    // 请求错误
    console.log('HTTP error', xhr.status, xhr.statusText);
  }
};

// 开始请求
xhr.send();</code>

Fetch peut être abandonné en appelant Controller.Abort (); La promesse sera rejetée, donc la fonction .catch () sera appelée.

pas de progrès

Au moment de la rédaction, Fetch ne prend pas en charge les événements de progression. Par conséquent, l'état des téléchargements de fichiers ou des soumissions de grande forme similaires ne peut pas être signalée.

xmlhttpRequest avec API Fetch?

fin du temps, le choix est sur vous ... à moins que votre application ait un client IE qui doit télécharger une barre de progression.

Pour les appels AJAX plus simples, XMLHttpRequest est de niveau inférieur, plus complexe et vous devrez envelopper la fonction. Malheureusement, une fois que vous commencez à réfléchir à la complexité des délais d'expiration, aux aborts et à la capture d'erreurs, Fetch a également besoin d'envelopper les fonctions.

Vous pouvez choisir un polyfill fetch qui est utilisé en conjonction avec le polyfill promesse, afin que vous puissiez écrire du code de fetch dans IE. Cependant, XHR est utilisé comme une secours;

Fetch est l'avenir. Cependant, l'API est relativement nouvelle, elle n'offre pas toutes les fonctionnalités XHR, et certaines options sont lourdes. Utilisez-le avec prudence dans les années à venir.

FAQS (FAQ) sur XMLHTTPREQUEST ET APIS FETCH

Quelles sont les principales différences entre l'API XMLHTTPREQUEST et FETCH?

XMLHTTPREQUEST et API Fetch sont tous deux utilisés pour faire des demandes HTTP dans JavaScript. Cependant, ils diffèrent de plusieurs manières. L'API Fetch est une technologie plus récente qui est considérée comme plus puissante et flexible. Il renvoie une promesse qui se résout à la demande, qu'elle réussisse ou non. Fetch fournit également des définitions communes des objets de demande et de réponse. D'un autre côté, XMLHTTPRequest est plus ancien et n'utilise pas la promesse, ce qui peut rendre le code plus complexe et plus difficile à maintenir. Il n'a pas de définition commune pour les objets de demande et de réponse.

L'API de récupération est-elle meilleure que XMLHttpRequest?

API Fetch est souvent considéré comme un meilleur choix pour faire des demandes HTTP en JavaScript en raison de l'utilisation de la promesse. Promise rend le code plus concis, plus facile à lire et facilite également la gestion des erreurs. La fonctionnalité de l'API Fetch est également plus puissante et flexible que XMLHttpRequest. Cependant, XMLHTTPRequest est toujours largement utilisé et pris en charge et peut être un meilleur choix dans certains cas, par exemple lorsque vous devez prendre en charge les navigateurs plus âgés qui ne prennent pas en charge l'API Fetch.

L'API a-t-elle récupéré peut-elle remplacer xmlhttprequest?

Oui, l'API Fetch peut remplacer le XMLHTTPRequest dans JavaScript qui est utilisé pour faire des demandes HTTP. L'API Fetch est une technologie plus récente et dispose d'un ensemble de fonctionnalités plus puissant et plus flexible. Il utilise Promise, ce qui rend le code plus concis, plus facile à lire et facilite également la gestion des erreurs. Cependant, XMLHTTPRequest est toujours largement utilisé et pris en charge et peut être un meilleur choix dans certains cas, par exemple lorsque vous devez prendre en charge les navigateurs plus âgés qui ne prennent pas en charge l'API Fetch.

Quels sont les avantages de l'utilisation de l'API Fetch?

API Fetch a plusieurs avantages par rapport à XMLHttpRequest. Il utilise Promise, ce qui rend le code plus concis, plus facile à lire et facilite également la gestion des erreurs. L'API Fetch a également un ensemble de fonctionnalités plus puissant et plus flexible, y compris les définitions courantes des objets de demande et de réponse. Il vous permet également de faire des demandes à d'autres sources, contrairement à XMLHttpRequest.

Quels sont les inconvénients de l'utilisation de l'API Fetch?

L'un des principaux inconvénients de l'utilisation de l'API Fetch est que tous les navigateurs ne le soutiennent pas. En particulier, les navigateurs plus anciens peuvent ne pas prendre en charge l'API Fetch. Dans ces cas, vous devrez peut-être utiliser XMLHttpRequest ou Polyfill. Un autre inconvénient est que l'API Fetch n'envoie pas de cookies par défaut, donc si vous souhaitez envoyer des cookies, vous devez définir manuellement l'option Identials pour "inclure".

Quels sont les avantages de l'utilisation de xmlhttprequest?

xmlhttprequest est une technologie éprouvée pour faire des demandes HTTP en JavaScript. Il est largement pris en charge et peut être utilisé dans tous les navigateurs. Contrairement à l'API Fetch, XMLHttpRequest envoie également des cookies par défaut. Cela peut être un avantage dans certains cas, par exemple lorsque vous faites une demande à un serveur qui nécessite des cookies pour s'authentifier.

Quels sont les inconvénients de l'utilisation de xmlhttprequest?

xmlhttpRequest n'utilise pas la promesse, ce qui peut rendre le code plus complexe et plus difficile à maintenir. Il n'a pas non plus de définition commune des objets de demande et de réponse et ne vous permet pas de faire des demandes à d'autres sources. XMLHTTPRequest est également considéré comme un peu dépassé par rapport aux technologies plus récentes telles que l'API Fetch.

Comment choisir API XMLHTTPREQUEST ET RECHERCHER?

La sélection des API XMLHTTPREQUEST et FETCH dépend de vos besoins spécifiques et du navigateur que vous devez prendre en charge. Si vous avez besoin de prendre en charge les navigateurs plus anciens qui ne prennent pas en charge l'API Fetch, XMLHTTPREQUEST peut être un meilleur choix. Cependant, si vous utilisez un navigateur plus récent et que vous souhaitez profiter de la syntaxe plus propre, plus moderne de l'API Fetch et un ensemble de fonctionnalités plus puissant et plus flexible, l'API Fetch sera un meilleur choix.

Puis-je utiliser à la fois API XMLHTTPREQUEST et FETCH dans le même projet?

Oui, vous pouvez utiliser à la fois des API XMLHTTPRequest et récupérer dans le même projet. Vous pouvez choisir d'utiliser XMLHTTPRequest pour certaines tâches et récupérer l'API pour d'autres tâches en fonction de vos besoins spécifiques et du navigateur que vous devez prendre en charge. Cependant, il est souvent recommandé de s'en tenir à l'un d'eux pour la cohérence et la facilité d'entretien.

Y a-t-il une autre API XMLHTTPREQUEST ET RETCH pour faire des demandes HTTP en JavaScript?

Oui, il existe plusieurs alternatives aux API XMLHTTPRequest et récupérer pour faire des demandes HTTP en JavaScript. Il s'agit notamment de bibliothèques telles que Axios, JQuery's $ .ajax et SuperAgent. Ces bibliothèques fournissent un niveau plus élevé d'interfaces pour effectuer des demandes HTTP et fournissent des fonctionnalités et des commodités supplémentaires par rapport aux API XMLHTTPRequest et Fetch.

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn