@wordpress/api-fetch
Définition : @wordpress/api-fetch est un paquet JavaScript WordPress qui facilite les requêtes HTTP vers la REST API du site. Il fournit une interface cohérente pour les chemins et certains middlewares.
Comprendre et utiliser
À quoi sert ce terme ?
Il simplifie la communication des interfaces d’administration et des blocs avec les endpoints REST WordPress. Cela évite de reconstruire manuellement l’URL racine et certains détails d’authentification déjà gérés par le contexte.
Fonctionnement technique
Le paquet expose une fonction apiFetch qui accepte notamment path, url, method et data selon le scénario. Les middlewares peuvent gérer l’ajout du nonce et la racine de l’API.
Dans quels contextes l’utiliser ?
Employer dans un composant JavaScript exécuté dans WordPress. Les endpoints privés restent soumis aux permissions du serveur, même si le navigateur dispose d’un nonce.
Cas concret : ATOOLPHA
ATOOLPHA souhaite lire une sélection de publications publiques depuis un panneau de consultation, sans créer un système HTTP propre au plugin.
Exemple de code commenté
Extrait JavaScript destiné à un fichier de ressources enregistré avec ses dépendances dans WordPress ; pas à coller dans le contenu public.
// Dans un fichier JS compilé avec @wordpress/scripts.
import apiFetch from '@wordpress/api-fetch';
async function loadPosts() {
try {
const posts = await apiFetch({ path: '/wp/v2/posts?per_page=3' });
return posts.map((post) => ({ id: post.id, title: post.title.rendered }));
} catch (error) {
console.error('Lecture REST impossible', error);
return [];
}
}
Décryptage de l’exemple
La fonction interroge l’endpoint public des articles et transforme le résultat en données de démonstration. Le champ rendered peut contenir du HTML : une application ne doit pas l’insérer aveuglément avec innerHTML.
Résultat attendu
Une liste d’objets contenant ID et titre est disponible si la requête réussit ; en cas d’erreur, un tableau vide est renvoyé.
Exercice pratique et vérification
Tester une lecture publique, puis une requête non autorisée vers une ressource privée sur un compte de test. Comparer les réponses HTTP.
Précautions et limites
Un nonce REST n’est pas une autorisation. Pour écrire des données, l’endpoint doit valider permissions, schéma et valeurs côté serveur.
À ne pas confondre
apiFetch est un client HTTP WordPress ; fetch() est l’API web native ; ni l’un ni l’autre ne crée automatiquement un endpoint.
Diagnostic avancé
Si une requête obtient 401/403, vérifier session, nonce, permissions et endpoint plutôt que de désactiver les contrôles de sécurité.
Choix d’architecture et déploiement
Le client REST doit traiter explicitement les erreurs et tenir compte du schéma des objets renvoyés. Les champs contenant du HTML ne doivent pas être interprétés comme du texte brut fiable, et les privilèges côté navigateur ne remplacent jamais permission_callback côté serveur.
Contrôle avant intégration
Vérifier le contexte d’authentification, la gestion des erreurs et l’échappement du titre lors de son insertion dans le DOM.
Notions associées
- REST API
- @wordpress/i18n
- Dépendances de scripts
