{"code":"rest_no_route","message":"No route was found matching the URL and request method.","data":{"status":404}}. C’est la réponse que reçoit une application mobile de gestion de commandes lorsqu’elle interroge l’API REST WooCommerce d’une boutique multilingue, mais seulement quand la requête cible une des langues secondaires du site — la langue par défaut, elle, répond normalement.
Ce comportement erratique, qui touche trois langues sur quatre dans le cas précis remonté par l’équipe technique, désoriente au premier abord : l’API fonctionne, elle répond correctement sur certains appels, puis échoue brutalement dès qu’un identifiant de langue entre en jeu dans le chemin de la requête.
Reproduire l’erreur : le préfixe de langue dans le chemin de l’API
L’application mobile, pour récupérer le catalogue produit dans la langue préférée de l’utilisateur, construisait ses appels API en préfixant l’URL avec le code de langue, sur le modèle de la navigation classique du site :
# Fonctionne
GET https://boutique.exemple.fr/wp-json/wc/v3/products
# Échoue avec rest_no_route
GET https://boutique.exemple.fr/de/wp-json/wc/v3/products
GET https://boutique.exemple.fr/es/wp-json/wc/v3/products
GET https://boutique.exemple.fr/it/wp-json/wc/v3/productsCette construction d’URL semblait logique côté équipe mobile, calquée sur le comportement observé pour les pages classiques du site, où /de/, /es/ et /it/ fonctionnent parfaitement pour naviguer dans chaque langue. L’API REST de WordPress, elle, ne fonctionne pas selon la même logique de résolution d’URL que les pages front-end.
Cause : l’espace de noms REST n’est jamais préfixé par la langue
L’API REST de WordPress s’enregistre sur un chemin fixe, /wp-json/, indépendant de toute structure de permalien multilingue gérée par Polylang ou WPML. Le système de réécriture d’URL qui permet à ces extensions de préfixer les pages classiques par une langue (/de/produit-x/) ne s’applique pas au routeur interne de l’API REST, qui attend strictement /wp-json/wc/v3/... à la racine du domaine, sans préfixe d’aucune sorte.
Quand la requête arrive avec un préfixe /de/ avant /wp-json/, WordPress ne reconnaît tout simplement pas cette route comme un point d’entrée valide de l’API REST, et renvoie l’erreur générique rest_no_route, la même erreur que produirait n’importe quelle URL d’API mal formée, sans lien direct avec le multilingue en apparence.
Correctif côté application : transmettre la langue en paramètre, jamais dans le chemin
La correction ne se situe pas côté WordPress mais côté client de l’API : la langue souhaitée doit être transmise comme paramètre de requête, pas comme segment du chemin d’URL. WooCommerce et Polylang/WPML exposent tous deux un paramètre standard à cet effet :
# Bonne pratique
GET https://boutique.exemple.fr/wp-json/wc/v3/products?lang=de
GET https://boutique.exemple.fr/wp-json/wc/v3/products?lang=esCe paramètre lang, reconnu par Polylang dès lors que son support de l’API REST est actif dans ses réglages, filtre les résultats retournés selon la langue demandée sans jamais toucher au chemin de la route elle-même, qui reste fixe et identique quelle que soit la langue interrogée.
Vérifier que le support REST est bien activé côté extension multilingue
Un point de configuration à ne pas négliger : Polylang doit avoir son support de l’API REST explicitement activé (réglage présent dans les options de l’extension), sans quoi le paramètre lang transmis en requête est tout simplement ignoré et l’API retourne les produits dans toutes les langues mélangées, un symptôme différent mais lié à la même racine de configuration.
- Vérifier la présence du paramètre
langdans la documentation de l’extension multilingue utilisée, WPML et Polylang ayant chacun leur propre implémentation - Tester chaque endpoint utilisé par l’application mobile avec et sans le paramètre, pour confirmer que le filtrage s’applique bien avant de déployer côté client
- Documenter ce comportement auprès de toute équipe externe qui consomme l’API, l’erreur
rest_no_routeétant trop générique pour orienter seule vers la bonne piste
En résumé
L’API REST de WordPress ne suit jamais la structure d’URL préfixée par langue utilisée pour les pages classiques d’un site multilingue : le chemin /wp-json/ reste fixe, et la langue doit être transmise en paramètre de requête, jamais en segment d’URL. Cette confusion, fréquente chez une équipe mobile qui découvre le multilingue côté API, produit une erreur générique rest_no_route qui n’oriente pas naturellement vers cette cause précise.
