# Pourquoi WooCommerce a remplacé ses appels Ajax historiques par la Store API > Retour sur les limites de l'ancien système Ajax de WooCommerce et sur les raisons techniques qui ont justifié la création d'une API REST dédiée au panier. - Auteur : WordPress Développement - Publié le : 2023-05-08 - Mis à jour le : 2023-05-08 - Catégorie : E-commerce - URL : https://www.wpmoderne.fr/ecommerce/pourquoi-woocommerce-remplace-ajax-store-api/ ## L’essentiel - Ajax dépendait du HTML rendu par le thème actif - La Store API décrit des données, pas du balisage - Elle ouvre la voie au commerce headless « La Store API est un ensemble de points d'entrée REST qui alimentent les blocs de panier et de paiement de WooCommerce Blocks. » Cette définition, reprise de la documentation officielle du projet WooCommerce Blocks, résume en une ligne pourquoi tout un pan du panier et du paiement a changé de fondations. Avant elle, ces deux étapes reposaient sur une mécanique Ajax construite au fil des versions, avec ses forces et ses angles morts. Comprendre pourquoi cette bascule a eu lieu aide à mieux exploiter la nouvelle API plutôt qu'à la subir comme une contrainte imposée par une mise à jour. ## Le système Ajax hérité : comment il fonctionnait Historiquement, la mise à jour du panier reposait sur des actions Ajax enregistrées via le préfixe `wc_ajax_`, utilisé par WooCommerce pour router des requêtes internes de façon plus légère qu'un appel classique à `admin-ajax.php`. Chaque interaction — ajout au panier, application d'un coupon, changement de quantité — déclenchait une requête POST vers un point d'entrée spécifique, qui renvoyait un fragment HTML régénéré côté serveur. Ce mécanisme de fragments, exposé par le filtre `woocommerce_add_to_cart_fragments`, permettait de rafraîchir des zones précises de la page, comme le mini-panier dans l'en-tête, sans recharger l'ensemble du document. Il a rendu de bons services pendant des années, notamment parce qu'il s'intégrait facilement à n'importe quel thème classique bâti sur des gabarits PHP. ## Les limites qui ont motivé une nouvelle API Trois problèmes structurels revenaient régulièrement dans les discussions du projet. Le premier tient au couplage fort entre logique métier et rendu HTML : une requête Ajax renvoyait souvent un balisage déjà mis en forme par le thème actif, ce qui rendait très difficile toute consommation du panier par un client autre qu'un navigateur affichant précisément ce thème. Le deuxième problème touchait la cohérence des données : sans contrat explicite, chaque extension pouvait modifier les fragments retournés, et deux extensions touchant le même fragment entraient facilement en collision. Le troisième concernait la testabilité : un point d'entrée qui mélange logique et rendu se couvre bien plus difficilement par des tests automatisés qu'un point d'entrée qui retourne une structure de données prévisible. > L'essentiel à retenir : Ajax dépendait du HTML rendu par le thème actif ; La Store API décrit des données, pas du balisage ; Elle ouvre la voie au commerce headless ## Ce que change concrètement la Store API La Store API expose des ressources REST classiques sous `/wc/store/v1` : `/cart`, `/cart/items`, `/cart/coupons`, `/checkout`, entre autres. Chaque réponse est un objet JSON structuré, avec des clés stables et documentées, indépendamment du thème actif. Le panier n'est plus « rendu » par le serveur puis renvoyé tel quel : il est décrit, et c'est le bloc JavaScript côté client qui décide comment l'afficher. Ce changement de responsabilité a une conséquence directe : un même point d'entrée peut désormais servir aussi bien l'interface graphique classique qu'une application mobile ou qu'un site détaché du thème WordPress pour son rendu. ## Cas d'usage concrets - Un thème enfant qui veut afficher le contenu du panier dans un panneau personnalisé sans dupliquer la logique de calcul des totaux. - Une extension qui ajoute un champ de livraison personnalisé et doit le faire apparaître de façon fiable dans la réponse du point de terminaison `/checkout`. - Un site qui expose son catalogue et son tunnel d'achat à un frontal découplé du thème, consommant uniquement des réponses JSON. ### Un exemple de requête ``` GET /wp-json/wc/store/v1/cart HTTP/1.1 Host: exemple-boutique.fr Accept: application/json ``` La réponse contient un objet avec, entre autres, les clés `items`, `coupons`, `totals` et `shipping_rates`, chacune documentée avec son schéma dans la référence technique du projet. ## Les pièges à connaître avant de migrer une extension Une extension construite autour des anciens fragments ne se convertit pas d'un simple copier-coller. Le piège le plus fréquent consiste à confondre les points d'entrée internes de la Store API, pensés d'abord pour les blocs officiels, avec une API publique figée au sens strict. Certains points restent susceptibles d'évoluer entre deux versions mineures, ce qui impose de suivre le journal de modifications de WooCommerce Blocks avant chaque montée de version. Autre piège classique : oublier que le mécanisme historique continue de fonctionner en parallèle sur les gabarits classiques. Un site qui mélange blocs de panier et gabarits hérités peut se retrouver avec deux sources de vérité différentes pour le même panier si une extension ne cible que l'une des deux mécaniques. ## En résumé La Store API n'est pas un simple habillage moderne posé sur l'ancien système Ajax : elle répond à un vrai problème d'architecture, celui d'un panier qui produisait du HTML plutôt que des données. Ce choix a un coût, celui d'une couche d'indirection supplémentaire, mais il ouvre la porte à des usages que le système Ajax historique ne pouvait tout simplement pas couvrir.