# Pourquoi la REST API a remplacé XML-RPC dans le cœur de WordPress

> Avant l'API REST, WordPress exposait déjà une interface de communication à distance via XML-RPC. Ce que cette dernière ne permettait pas et que le nouveau protocole a résolu.

- Auteur : WordPress Développement
- Publié le : 2024-02-17
- Mis à jour le : 2024-02-17
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/rest-api-remplace-xml-rpc-coeur-wordpress/

## L’essentiel

- XML-RPC existait dans WordPress bien avant l'API REST moderne
- Le format JSON et les verbes HTTP ont rendu l'intégration côté web plus naturelle
- L'intégration au cœur s'est faite progressivement, pas en une seule version

Bien avant que le terme « headless » n'entre dans le vocabulaire courant des développeurs WordPress, le cœur du logiciel disposait déjà d'un moyen de communiquer avec l'extérieur sans passer par une page HTML rendue : le protocole XML-RPC, actif dès les premières versions et toujours présent aujourd'hui via le fichier `xmlrpc.php`. Comprendre pourquoi ce protocole n'a pas suffi à porter l'essor du développement découplé éclaire les choix qui ont façonné l'API REST actuelle.

XML-RPC répondait à un besoin précis en son temps : permettre à des applications de bureau, comme certains logiciels de rédaction hors ligne, de publier du contenu à distance sur un blog WordPress. Ce cas d'usage, pertinent au milieu des années deux mille, ne correspondait déjà plus aux besoins d'un web dominé par JavaScript et les échanges asynchrones au moment où l'idée d'une API plus moderne a commencé à germer.

## Les limites concrètes de XML-RPC

Le format XML, verbeux par nature, imposait un surcoût de traitement et de taille de message par rapport au JSON qui s'est imposé entre-temps comme format d'échange de référence sur le web. Chaque appel XML-RPC repose également sur une méthode unique, généralement en `POST`, qui encapsule dans son corps le nom de l'action demandée, plutôt que de s'appuyer sur les verbes HTTP standards (`GET`, `POST`, `PUT`, `DELETE`) pour exprimer nativement l'intention de la requête.

### Une découverte de service peu naturelle pour le web moderne

Un client JavaScript exécuté dans un navigateur, ou une application mobile, s'intègre plus naturellement avec une interface qui expose des ressources identifiées par des chemins d'URL distincts (`/wp/v2/posts/42`) que par un unique point d'entrée générique qui multiplexe toutes les actions possibles selon le contenu du corps de la requête envoyée.

## La genèse de l'API REST dans le cœur

Le développement de l'API REST moderne a débuté comme un plugin distinct, distribué séparément du cœur, développé et affiné pendant plusieurs années par une équipe dédiée avant son intégration progressive. Cette approche par étapes, plutôt qu'une bascule brutale, a permis de tester le format en conditions réelles sur de nombreux sites avant d'engager sa fusion définitive dans le logiciel principal.

> L'essentiel à retenir : XML-RPC existait dans WordPress bien avant l'API REST moderne ; Le format JSON et les verbes HTTP ont rendu l'intégration côté web plus naturelle ; L'intégration au cœur s'est faite progressivement, pas en une seule version

## Ce qui a changé concrètement pour les développeurs

- Un format d'échange en JSON, plus léger et plus naturellement manipulable en JavaScript qu'un document XML.
- Des chemins de ressources explicites, structurés autour des types de contenus, plutôt qu'une méthode générique unique.
- Une extensibilité native via `register_rest_route()`, permettant à toute extension d'ajouter ses propres points d'entrée sans modifier le cœur.
- Un mécanisme de schéma et de validation des arguments intégré à la déclaration même de chaque route.

## XML-RPC n'a pourtant pas disparu

Contrairement à une idée reçue, XML-RPC reste actif par défaut sur une installation WordPress actuelle, principalement pour assurer la rétrocompatibilité avec certains outils historiques et avec le protocole Pingback. Cette persistance explique pourquoi le fichier `xmlrpc.php` continue de figurer parmi les cibles fréquentes de tentatives d'authentification automatisées, un sujet de sécurité distinct de son rôle historique dans l'histoire du développement à distance sous WordPress.

## Ce que cette histoire enseigne pour aujourd'hui

La coexistence prolongée de deux protocoles au sein du même logiciel illustre une constante du développement du cœur de WordPress : les évolutions majeures s'y font rarement par remplacement brutal, mais par ajout progressif, suivi d'une longue période de transition où l'ancien mécanisme continue de fonctionner en parallèle du nouveau, souvent pendant plusieurs années.

> Un protocole qui répondait parfaitement aux besoins de son époque peut devenir un frein une décennie plus tard, sans qu'aucune de ses caractéristiques d'origine n'ait objectivement changé entre-temps.

## Pour aller plus loin

Les archives publiques du système de suivi de tickets de WordPress, consultables sur core.trac.wordpress.org, permettent de retracer précisément les différentes étapes qui ont mené à l'intégration de l'API REST au cœur du logiciel. Cette rétrospective éclaire utilement les choix de conception encore visibles aujourd'hui dans la structure des routes et des schémas de l'API actuelle.