API Fetch

Avant l’API Fetch, envoyer une requête HTTP en JavaScript passait presque toujours par XMLHttpRequest, une interface fonctionnelle mais verbeuse, construite autour d’événements plutôt que de promesses. fetch() a modernisé cette écriture : un simple appel de fonction renvoie une promesse, que l’on chaîne avec .then() ou que l’on attend avec await dans une fonction asynchrone, pour un code sensiblement plus court et plus lisible.

Fetch et l’API REST de WordPress

Depuis l’introduction de l’éditeur de blocs, WordPress encourage l’usage de fetch() (souvent via son enveloppe wp.apiFetch, qui ajoute automatiquement le jeton de sécurité nécessaire) pour dialoguer avec l’API REST en /wp-json/. Un bloc personnalisé qui doit charger la liste des catégories ou enregistrer une valeur de champ appellera typiquement apiFetch plutôt que fetch() brut, pour bénéficier de cette gestion intégrée des permissions.

Exemple

fetch( '/wp-json/wp/v2/posts?per_page=5' )
  .then( reponse => reponse.json() )
  .then( articles => console.log( articles ) )
  .catch( erreur => console.error( erreur ) );

Pièges fréquents

• fetch() ne rejette pas automatiquement sa promesse pour une réponse en erreur HTTP (404, 500) : il faut vérifier soi-même la propriété response.ok, sans quoi une erreur serveur peut passer inaperçue.
• Oublier d’attendre la conversion du corps de la réponse (response.json() renvoie elle-même une promesse) et tenter d’utiliser directement l’objet Response comme s’il contenait déjà les données.
• Ne pas gérer le jeton de sécurité (X-WP-Nonce) requis par l’API REST de WordPress pour les actions d’écriture, ce qui provoque une erreur 403 silencieuse si on utilise fetch() nu plutôt que apiFetch.