Comment supprimer les routes et les points de terminaison de l'API REST WordPress par défaut

L'API REST de WordPress a été introduite dans le noyau dans la version 4.7 (Vaughan) en décembre 2016. Comme toute autre modification importante apportée au noyau WP, elle a été âprement débattue (en ce moment, juillet 2018, Gutenberg fait l'objet d'un tel débat/ controverse). Au final, il ne s'est rien passé. Ceux qui ne se soucient pas de l'API REST ne s'en soucient toujours pas. Ceux qui s'en soucient ont créé des applications, des intégrations, des plugins et d'autres projets sympas.

Et pendant que nous parlons de projets sympas. Savez-vous que les plus réussies commencent par une page à venir ? Et dans de nombreux cas, il s'agit d'une page à venir qui a été créée à l'aide du plugin Coming Soon & Maintenance Mode.

Ce plugin est livré avec un générateur de glisser-déposer, plus de 170 thèmes, une configuration SEO de premier ordre, des services de répondeur automatique et d'e-mailing, et de nombreuses autres fonctionnalités qui vous permettront de créer la page parfaite à venir en quelques minutes. Et en plus de tout cela, le plugin est intégré à Depositphotos, ce qui signifie que vous pouvez trouver les meilleurs visuels directement depuis le plugin. Mais au cas où vous n'êtes pas fan de la collection proposée par Depositphotos, Yay Images est également une excellente source de contenu stock.

Mais assez parlé de cela, revenons à notre sujet principal, l'API REST.

Nous nous soucions de l'API REST et l'utilisons lors de la création de SaaS alimentés par WP. Il est stable, rapide, facile à utiliser, s'intègre parfaitement dans WP et dans la plupart des cas bien documenté. Si vous ne savez pas ce qu'est l'API REST, ce n'est probablement pas le poste pour vous, mais vérifiez ce qu'est l'API REST (vidéo et texte) et peut-être que vous l'utiliserez dans votre prochain projet.

Itinéraire? Point final ? N'est-ce pas la même chose ?

Non, ce n'est pas pareil. La différence est subtile pour la plupart des gens, et ils utilisent les termes route et endpoint de manière interchangeable, mais ce n'est pas si compliqué. La route est plus ou moins l'URL. Il s'agit du « nom » utilisé pour accéder à un point de terminaison. Sur une seule route, vous pouvez avoir plusieurs points de terminaison car le point de terminaison que vous utilisez dépend du type de requête HTTP que vous utilisez. GET , POST , PUT ou DELETE peuvent, et servent généralement à des fins différentes. En accédant à yoursite.com/wp-json/v2/posts/1 via GET , vous obtiendrez les détails de la publication avec l'ID #1. L'utilisation de DELETE sur le même itinéraire appellera un point de terminaison différent (ou une fonction si vous le souhaitez) qui supprime ce message. Le manuel officiel de l'API REST contient plus d'informations à ce sujet, alors plongez pour plus de détails.

Pourquoi supprimerais-je les points de terminaison ou les routes par défaut de l'API WP REST ?

Comme nous en avons discuté dans l'article sur la suppression des règles de réécriture par défaut, il existe une centaine de raisons pour lesquelles un développeur WordPress ferait cela.
"Cela rendra WordPress plus rapide car il n'a pas à analyser tous ces points de terminaison." est toujours quelque chose avec lequel je ne suis pas d'accord et je pense que le gain sera inférieur à une milliseconde, mais cela ne peut pas faire de mal.

Vous aimez garder les choses propres et puisque vous n'utilisez pas l'API REST, pourquoi avoir des routes d'API ? Bien sûr, c'est logique. Mais dans ce cas, utilisez un plugin pour désactiver complètement l'API REST.

Et puis il y a la raison pour laquelle nous désactivons les routes par défaut (et les points de terminaison). Nous utilisons beaucoup les points de terminaison d'API REST personnalisés, mais nous n'avons pas besoin de ceux par défaut. Par conséquent, il est agréable de garder les choses maigres et propres. Cela ne peut pas non plus nuire à la sécurité, car nous exposons moins de données au monde extérieur hostile.

Montrez-moi les points de terminaison d'API par défaut

La référence du point de terminaison est disponible dans le manuel de l'API REST. Plus ou moins, toutes les données accessibles au public seront également disponibles via l'API REST. Un exemple de demande à demo.wp-api.org/wp-json/wp/v2/posts affichera dix messages au format JSON. Si vous voulez une version lisible par l'homme de cette réponse, vous devrez décoder la réponse JSON. Il en va de même pour les pages, catégories et autres structures de données. La structure de données et les points de terminaison sont très similaires, comme vous pouvez le voir si vous parcourez la référence.

L'autre façon de voir les routes par défaut est d'ajouter ce code au fichier functions.php de votre thème, puis d'ouvrir yoursite.com/wp-json/. Activez les jolis liens si vous ne l'avez pas déjà fait.

add_filter( 'rest_endpoints', 'show_default_endpoints' );
 
function show_default_endpoints( $endpoints ) { 
  var_export( array_keys( $endpoints ) );
  die;
}

Il affiche les 31 points de terminaison REST par défaut. Le nombre est, bien sûr, susceptible de changer à mesure que de nouvelles fonctionnalités de base sont ajoutées. Et ce sera différent si vous avez des plugins qui ajoutent des points de terminaison personnalisés.

Suppression des points de terminaison par défaut

Le code ci-dessus nécessite un minimum de modifications. Renvoie un tableau vide et tous les points de terminaison ont disparu.

add_filter( 'rest_endpoints', 'remove_default_endpoints' );
 
function remove_default_endpoints( $endpoints ) { 
  return array( );
}

"Tous les points de terminaison" inclut également vos points de terminaison personnalisés, il est donc sage de ne pas les supprimer. Voici un moyen simple de les garder actifs :

add_filter( 'rest_endpoints', 'remove_default_endpoints_smarter' );
 
function remove_default_endpoints_smarter( $endpoints ) { 
  $prefix = 'your_custom_endpoint_prefix';

  foreach ( $endpoints as $endpoint => $details ) {
    if ( !fnmatch( '/' . $prefix . '/*', $endpoint, FNM_CASEFOLD ) ) {
      unset( $endpoints[$endpoint] );
    }
  }

  return $endpoints;
}

Ignorez simplement les points de terminaison avec votre préfixe personnalisé et conservez-les dans le tableau. N'oubliez pas de retourner le tableau.

Personnalisation du préfixe de l'URL REST

Les points de terminaison personnalisés, bien qu'ils soient personnalisés, utilisent le même préfixe que les points de terminaison par défaut. Ils ressemblent à mysite.com/wp-json/custom-endpoint/. Peut-être que vous trouvez cela moche ou que vous n'aimez pas les choses par défaut. Le changer est une question d'une ligne de code. À des fins de test, placez le code ci-dessous dans functions.php du thème et après avoir enregistré, ouvrez Dashboard - Settings - Permaliens pour vider les règles de réécriture.

add_filter( 'rest_url_prefix', 'rest_url_prefix' );

function rest_url_prefix( ) {
  return 'api';
}

Avec le filtre au-dessus, vos points de terminaison seront mysite.com/api/custom-endpoint/ et l'ouverture de l'ancienne URL mysite.com/wp-json/custom-endpoint/ produira une erreur 404.

Assurez-vous d'inclure un numéro de version dans vos points de terminaison personnalisés car un préfixe n'est pas ajouté automatiquement par WP. Un préfixe de numéro de version garantit que les modifications ultérieures n'interrompent pas les clients qui utilisent les anciens points de terminaison. Incluez simplement le préfixe de version lors de l'appel de register_rest_route() pour obtenir quelque chose comme mysite.com/api/v1/custom-endpoint/ et gardez tous vos points de terminaison derrière ce "v1" afin que vous puissiez avoir "v2" etc plus tard.

Testez vos modifications

La suppression ou la modification des routes et des points de terminaison de l'API REST ne fera aucune différence sur 98 % des sites WP. "Pourquoi?" – Parce qu'ils n'utilisent pas du tout l'API REST. Mais si le vôtre le fait, assurez-vous de tester les applications connectées car, comme pour tout, les changements peuvent casser des choses. Et il vaut mieux repérer un bug aujourd'hui que demain.