rest_no_route sur WordPress : corriger l’adresse et la méthode de l’API

Lire le code rest_no_route avant de traiter toute erreur 404

Une requête d’éditeur, de formulaire ou d’intégration renvoie un objet contenant le code rest_no_route et un statut 404. Dans le cœur WordPress, ce résultat signifie qu’aucun traitement n’a correspondu au chemin et à la méthode HTTP de cette demande. L’adresse peut être incorrecte, la méthode incompatible ou la route ne pas être enregistrée dans l’installation interrogée.

Une route est le chemin logique d’une ressource dans l’API. Une même route peut proposer plusieurs actions, choisies par la méthode : lire, créer ou modifier ne constituent pas la même demande. Copier uniquement l’URL dans un navigateur change souvent ce que vous essayez de reproduire.

Le résultat recherché est que le client appelle le point d’accès réellement fourni par le site, avec sa méthode prévue. Une page HTML « introuvable » produite par le serveur ne démontre pas cette erreur applicative. Conservez donc le corps de réponse exact avant de régénérer les permaliens, changer les droits ou réinstaller des composants. Ces interventions ne corrigent pas automatiquement une méthode ou un namespace erroné.

Retrouver la requête réellement envoyée

Ouvrez le panneau Réseau des outils de développement du navigateur, puis observez l’action qui échoue. Sur une action pouvant envoyer un message, créer un contenu ou lancer une opération commerciale, utilisez la trace existante ; ne multipliez pas les essais en production. Une copie privée avec les effets externes neutralisés convient mieux à une reproduction contrôlée.

Relevez séparément la méthode, l’adresse finale, les paramètres et la réponse. Un export complet peut contenir des cookies ou des secrets ; préférez un relevé ciblé et expurgé. La mention 404 seule est insuffisante pour distinguer un refus de routage WordPress d’une réponse d’un intermédiaire.

Dans Chrome, ouvrez le menu ⋮ > Plus d’outils > Outils de développement, puis l’onglet Network ou Réseau. Sélectionnez la requête : Headers ou En-têtes contient l’adresse et la méthode ; Response ou Réponse contient le corps retourné ; Payload ou Charge utile affiche les paramètres transmis. Si la requête n’a pas été enregistrée, préparez sa reproduction sans effet externe sur la copie avant de la relancer. Un filtre Fetch/XHR peut aider, mais retirez-le si la demande recherchée est une navigation.

1. Sélectionnez la requête concernée dans Réseau et notez la méthode affichée, par exemple GET ou POST.
2. Relevez le domaine, le chemin, les paramètres et une éventuelle redirection.
3. Lisez la réponse et confirmez la présence exacte de rest_no_route.
4. Notez l’heure, le contexte connecté ou public et la fonction attendue.
5. Conservez ces éléments avant de modifier le client. Un test GET effectué ailleurs ne remplace pas la trace d’une soumission POST.

Retrouver la racine REST du site interrogé

Le préfixe habituel est /wp-json/, mais l’adresse doit être découverte sur le site concerné. Une installation en sous-dossier, des permaliens simples ou une personnalisation peuvent produire une autre racine. L’adresse de l’accueil et celle des fichiers du cœur ne doivent pas être assemblées au hasard.

WordPress expose normalement un lien de découverte portant la relation https://api.w.org/, dans les en-têtes ou le code source de la page. Dans le code source de l’accueil, recherchez cette relation et relevez son adresse associée. Sur une configuration à permaliens simples, elle peut utiliser ?rest_route=/ au lieu du préfixe réécrit.

Ouvrez uniquement la racine découverte du site que vous êtes autorisé à examiner. Elle doit décrire l’API plutôt qu’afficher le contenu d’un autre domaine ou un formulaire de connexion d’hébergement. Si une redirection change le domaine ou le sous-dossier, vérifiez la configuration du client et le serveur réellement visé. Ne désactivez pas une protection d’environnement pour rendre l’index public ; utilisez l’accès de diagnostic prévu pour cette copie.

Sur un réseau multisite, partez d’une page du sous-site concerné pour découvrir sa racine. Sur WordPress.com ou une plateforme gérée, utilisez l’API réellement prévue pour l’intégration et ses accès disponibles ; ne remplacez pas sa base par celle d’une documentation destinée à une autre installation. Ce diagnostic du client ne nécessite pas, à lui seul, un accès SSH.

Comparer la route à l’index de l’installation

L’index REST peut décrire les namespaces, les routes et les méthodes exposées. Un namespace regroupe des points d’accès, par exemple celui des ressources du cœur ou celui d’une extension. Une route présente dans une documentation n’est pas nécessairement disponible dans la version du composant installée sur votre site.

Dans la réponse de l’index, recherchez le namespace puis le chemin concernés. Certaines entrées contiennent une expression décrivant un identifiant variable ; elles ne correspondent pas à un nom de fichier à trouver par SFTP. Par exemple, une route d’article attend un identifiant numérique, pas nécessairement le slug visible dans son adresse publique.

1. Identifiez la racine correcte puis ouvrez sa réponse de découverte.
2. Cherchez le namespace et le chemin attendus dans les routes annoncées.
3. Comparez la méthode acceptée avec celle relevée dans le navigateur.
4. Vérifiez la version de la documentation utilisée et celle du composant installé.
5. Si l’index est filtré ou masqué, ne concluez pas à l’absence certaine de route : faites confirmer son enregistrement par le mainteneur sans lever globalement la protection.

Utiliser la méthode prévue sans transformer une lecture en écriture

Une URL prévue pour une soumission peut refuser GET tout en acceptant POST. L’ouvrir dans la barre d’adresse ne teste donc pas la soumission d’origine. De même, envoyer une modification sur le chemin d’une collection au lieu de celui d’un élément peut ne correspondre à aucun traitement prévu.

Consultez la documentation du point d’accès exact. Dans un client d’API ou un connecteur existant, vérifiez le champ de méthode et le champ d’URL ensemble. Ne choisissez pas POST parce qu’il ferait disparaître le message : sur une route adaptée, cette méthode peut créer une ressource ou déclencher un envoi.

Si une demande traverse une redirection, observez aussi la méthode et l’adresse de la requête finale. Corrigez de préférence le client pour qu’il vise directement l’adresse canonique documentée. N’utilisez pas un paramètre de remplacement de méthode pour contourner une règle sans en comprendre les effets. Le test de lecture ci-dessous évite les méthodes d’écriture ; toute validation d’une création ou modification doit être préparée séparément sur une copie et avec un contenu prévu à cet effet.

Effectuer une lecture courte sans identifiants

Pour distinguer un problème général d’adressage d’une route spécifique, vous pouvez lire un seul article public avec curl déjà disponible. Les exemples supposent la racine habituelle d’une installation à la racine du domaine. Remplacez les adresses par celles découvertes pour votre site ; ne les appliquez pas telles quelles à un site en sous-dossier.

Lancez séparément les deux commandes depuis un terminal. Sous PowerShell Windows, utilisez curl.exe à la place de curl. Elles demandent une collection publique réduite, sans identifiants, et limitent la durée du téléchargement. Une liste vide peut être normale si aucun article public ne correspond ; elle reste différente d’une erreur de route.

La seconde forme passe le chemin par rest_route et sert à comparer l’adressage. Si cette forme fonctionne alors que la première renvoie une page HTML 404, examinez la réécriture. Si les deux fonctionnent mais que l’extension échoue, concentrez-vous sur sa route, sa méthode et son contexte. Ce contrôle ne valide ni vos droits d’écriture ni la disponibilité d’une route fournie par un autre composant.

L’option --include affiche aussi le statut et les en-têtes avant le corps. Une redirection n’est pas suivie automatiquement : examinez sa destination et corrigez la base appelée si nécessaire. Gardez cette sortie privée et expurgez d’éventuels cookies avant transmission. Un refus de protection sur la copie doit être traité avec son accès prévu, sans rendre cette copie publique.

curl --include --max-time 20 --get --data-urlencode 'per_page=1' --data-urlencode '_fields=id,link' 'https://votre-site.example/wp-json/wp/v2/posts'
curl --include --max-time 20 --get --data-urlencode 'rest_route=/wp/v2/posts' --data-urlencode 'per_page=1' --data-urlencode '_fields=id,link' 'https://votre-site.example/'

Corriger le client lorsque la route existe

Lorsque la route et la méthode sont bien présentes sur la bonne installation, comparez leur définition avec la demande réelle du client. Un ancien domaine, un préfixe répété, une version de namespace obsolète ou un identifiant placé au mauvais endroit suffit à produire une demande différente de celle prévue.

Conservez la configuration initiale du connecteur en privé. Les menus varient selon le logiciel : repérez sa configuration de connexion existante, puis les champs d’URL de base, de chemin et de méthode. Ne dupliquez pas la racine REST si le logiciel l’ajoute déjà. Ne placez pas non plus un identifiant secret dans l’URL pour compenser un autre échec.

1. Corrigez uniquement le domaine, le chemin ou la méthode dont l’écart est confirmé.
2. Enregistrez la configuration sur la copie ou dans son profil de test.
3. Effectuez une lecture documentée sans effet externe pour vérifier la cible.
4. Pour une écriture, utilisez ensuite un contenu de test et vérifiez qu’aucune opération n’a été créée en double.
5. Si le résultat se dégrade, rétablissez les champs précédents. Conservez la preuve avant et après plutôt que de modifier simultanément l’authentification et le routage.

Rétablir le composant propriétaire d’une route absente

Si la route est fournie par une extension, sa disponibilité dépend de son chargement et de sa version. Dans Extensions > Extensions installées, vérifiez le composant propriétaire identifié par sa documentation, son état et ses dépendances. La présence de ses fichiers sur le disque ne prouve pas qu’il est chargé pour ce site ou dans ce contexte.

Sur une copie sauvegardée, si ce composant était volontairement prévu mais désactivé par erreur, vérifiez ses prérequis puis activez uniquement celui-ci. Rouvrez l’index et comparez la route. Si l’activation produit une erreur critique, revenez à l’état antérieur et examinez le journal ; n’activez pas tous les composants à la suite pour chercher celui qui ferait revenir la route.

Si le problème suit une mise à jour, comparez les versions du client et du composant. Une route supprimée ou renommée réclame une adaptation documentée du client, pas la création d’une route ouverte portant l’ancien nom. Pour du code personnalisé, le mainteneur doit vérifier son enregistrement au moment prévu, notamment lors de rest_api_init. Ne modifiez pas les fichiers du cœur ni une extension tierce pour ajouter un traitement qui contournerait ses contrôles.

Vérifier les particularités d’un type de contenu personnalisé

Un contenu visible dans le tableau de bord n’est pas automatiquement exposé par l’API REST sous le nom supposé par un connecteur. Son enregistrement peut définir la prise en charge REST et une base différente de son libellé public. Un type nommé « événements » dans l’interface peut ainsi ne pas utiliser le chemin deviné à partir de ce mot.

Consultez les réglages du composant qui déclare ce type et sa documentation. Recherchez sa prise en charge REST, sa base et, s’il est personnalisé, son contrôleur. Le mainteneur peut comparer l’enregistrement effectif avec show_in_rest et rest_base, sans changer immédiatement leurs valeurs.

N’activez pas l’exposition REST de contenus sensibles simplement pour satisfaire un outil. Faites confirmer quelles ressources et quels droits sont prévus. Si la route correcte existe sous une autre base, corrigez le client. Si la prise en charge manque réellement et doit être ajoutée, cette évolution nécessite une validation fonctionnelle et des permissions appropriées sur une copie. Elle dépasse le remplacement d’un mot dans l’URL et ne se résout pas en supprimant les contrôles d’accès du serveur.

Traiter la réécriture seulement lorsque la comparaison l’indique

Si le format avec rest_route fonctionne et que le chemin réécrit ne rejoint pas WordPress, vous avez un indice sur le routage du serveur. Un objet JSON rest_no_route doit d’abord être analysé comme un refus applicatif de routage ; il faut donc conserver cette distinction avant de remplacer des règles serveur.

Sur une copie, vérifiez l’adresse et les permaliens attendus. Pour un serveur Apache, les règles applicables peuvent se trouver dans la configuration du site ou dans son .htaccess autorisé. Sur Nginx, modifier .htaccess n’a pas cet effet. Utilisez le parcours propre au serveur identifié plutôt qu’un bloc de règles générique trouvé pour un autre hébergement.

Une sauvegarde des règles et un contrôle de syntaxe sont nécessaires avant leur application par le responsable. Le guide des permaliens traite cette réparation précise ; ici, l’objectif est de fournir la comparaison qui la justifie. Après correction, vérifiez l’adresse REST canonique et quelques pages normales. Une règle qui répare l’API mais casse les médias ou l’administration ne constitue pas une validation complète.

Changer de diagnostic lorsque le code de réponse change

Après correction de la route, un autre résultat peut apparaître. Un refus 401 ou 403 concerne alors l’identité ou les permissions, et un code rest_invalid_param concerne les arguments reçus. Ces résultats ne prouvent pas que le changement de chemin a échoué : la requête a pu atteindre une étape différente.

Lisez le code complet et les détails plutôt que de poursuivre le dépannage de routage par habitude. Un identifiant numérique bien formé mais inexistant peut également provoquer une erreur de ressource introuvable différente de rest_no_route. L’API a alors reconnu le type de chemin sans trouver l’élément demandé.

Aucune nouvelle extension n’est nécessaire pour comparer adresse, méthode et route enregistrée. Un outil qui désactive globalement les restrictions REST pourrait au contraire masquer une erreur ou élargir l’accès sans corriger le client. Utilisez d’abord le navigateur, la découverte native et la lecture documentée. Les secrets d’application et leurs révocations relèvent d’un parcours distinct, déjà disponible, lorsque les indices montrent que l’authentification est le vrai blocage.

Contrôler le fonctionnement réel après la correction

Validez la même opération que celle observée au départ, dans le même contexte utilisateur et sur le même environnement. Le succès d’une lecture d’articles publics ne garantit pas celui d’un formulaire ou d’une modification. Il confirme seulement que ce point d’accès de lecture fonctionne.

Sur la copie, utilisez un contenu de test et des destinations externes neutralisées pour la fonction qui était en échec. Si une ancienne tentative a pu produire un effet, recherchez cet effet avant de la répéter. Une intégration qui relance automatiquement sa demande doit être reprise selon son mécanisme documenté, sans recréer le même événement en parallèle.

1. Vérifiez l’adresse finale et la méthode de la requête après correction.
2. Confirmez la disparition de rest_no_route sur le parcours concerné.
3. Lisez le nouveau résultat et contrôlez l’effet attendu dans l’application.
4. Vérifiez aussi un parcours public et un parcours connecté qui fonctionnaient avant l’intervention.
5. Archivez le relevé expurgé, le réglage corrigé et le retour arrière prévu. Ne considérez pas la seule disparition du statut 404 comme une preuve de succès métier.

Revenir à la configuration précédente et préparer la suite

Si la correction ne convient pas, restaurez seulement les champs du client ou le composant que vous avez réellement modifiés. Pour une configuration serveur, faites remettre le fragment initial puis appliquer le contrôle et le rechargement propres au service. Ne restaurez pas toute la base pour annuler une simple adresse de connexion si aucune autre donnée n’a changé.

Consignez la racine REST retenue, le namespace, la route, la méthode et la version du composant qui les fournit. Ce relevé évite qu’un futur changement de domaine ou de version laisse un ancien chemin dans un logiciel externe. Pour un client développé sur mesure, demandez qu’il utilise la découverte et les chemins documentés au lieu d’assembler systématiquement /wp-json/ à une adresse supposée.

Pour poursuivre avec le mainteneur, transmettez la requête expurgée, la réponse exacte, l’heure et la comparaison avec l’index. Ajoutez le résultat du format alternatif si vous l’avez testé, ainsi que les versions des deux côtés. Indiquez clairement ce qui a été confirmé et ce qui reste une hypothèse. Ces éléments permettent une correction ciblée du client ou de l’enregistrement sans ouvrir toute l’API ni réinstaller le site.