Когда нам нужно вытащить посты, товары или ACF-поля с одного сайта и показать их на другом, многие до сих пор тянутся к RSS-лентам или, что еще хуже, пытаются вставить iframe. Обычно это заканчивается слезами: всё тормозит, дизайн не кастомизируется, а код превращается в один большой костыль.

WordPress REST API решает эту проблему на уровне архитектуры. Вы получаете чистенький, аккуратный JSON, который можно скормить чему угодно — хоть React-приложению, хоть простенькому PHP-скрипту, хоть мобильному приложению.

Но магия не в том, чтобы просто дернуть wp-json/wp/v2/posts. Настоящая инженерная работа начинается, когда мы настраиваем фильтры, кеш и безопасность. Давайте разберем 3 главных приема, которые отделяют джуниора от мидла при работе с WP API.

1. Тонкая настройка запросов: не тащите весь мусор

По умолчанию запрос к эндпоинту постов вываливает на вас тонну данных: ID автора, форматы, кучу ссылок, мета-поля, сырой контент и отрендеренный. Если вам нужно просто вывести список новостей (заголовок + ссылка + дата), зачем вам этот багаж?

Используйте параметр _fields. Он сокращает вес ответа в 3-4 раза.

Пример на JavaScript (fetch):

// Запрашиваем ТОЛЬКО нужные поля. Быстро и легко.
fetch('https://site.com/wp-json/wp/v2/posts?_fields=id,title,link,date')
  .then(response => response.json())
  .then(posts => {
    posts.forEach(post => {
      console.log(`Новость: ${post.title.rendered} | Дата: ${post.date}`);
    });
  });

А если вам нужны хитрые данные (например, сложная логика из ACF), не пытайтесь собирать их на клиенте. Напишите свой эндпоинт.

Пример регистрации кастомного роута (PHP):

add_action( 'rest_api_init', function () {
    register_rest_route( 'myplugin/v1', '/custom-data/', array(
        'methods' => 'GET',
        'callback' => 'my_custom_api_logic',
    ) );
} );

function my_custom_api_logic() {
    // Делаем сложные запросы к БД, собираем нужный массив
    // и отдаем клиенту только чистую выжимку.
    return array( 'status' => 'success', 'custom_value' => 42 );
}

2. Авторизация без боли: Application Passwords

Допустим, внешний сайт должен не только читать данные, но и писать (например, публиковать заявки с лендинга в виде черновиков постов). Стандартная авторизация по кукам тут сломает вам зубы из-за CORS и разных доменов.

Ваш бро — Application Passwords (пароли приложений), встроенные в ядро WordPress.

Главное правило безопасности: НИКОГДА не генерируйте этот пароль для админа. Создайте системного пользователя с ролью "Автор" или "Редактор" (в зависимости от задачи). Даже если этот ключ кто-то перехватит, он не сможет удалить плагины или снести тему.

Пример отправки поста (JavaScript):

const wpUrl = 'https://site.com/wp-json/wp/v2/posts';
const user = 'api_author';
const appPassword = 'XXXX XXXX XXXX XXXX XXXX XXXX'; // Ваш сгенерированный пароль

fetch(wpUrl, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Basic ' + btoa(user + ':' + appPassword) // Кодируем в Base64
  },
  body: JSON.stringify({
    title: 'Новая заявка с лендинга',
    content: 'Текст заявки...',
    status: 'draft' // Сохраняем как черновик от греха подальше
  })
});

3. Кеширование: как не убить свой хостинг

Запомните: каждый запрос к REST API без кеша — это полноценная загрузка ядра WordPress и запросы к базе. Если ваш React-фронтенд будет запрашивать посты при каждом клике 10 000 посетителей, ваш сервер просто выйдет покурить. И не вернется.

Самый простой и элегантный путь — использовать Транзиенты (Transients API) на принимающей стороне (если это PHP-сайт), либо кешировать ответы на уровне Redis/Memcached.

Пример кеширования на принимающем PHP-сайте:

$cache_key = 'remote_wp_posts_cache';
$posts = get_transient( $cache_key );

if ( false === $posts ) {
    // Данных в кеше нет, стучимся в API
    $response = wp_remote_get( 'https://remote-site.com/wp-json/wp/v2/posts?_fields=title,link' );
    
    if ( ! is_wp_error( $response ) && wp_remote_retrieve_response_code( $response ) === 200 ) {
        $posts = json_decode( wp_remote_retrieve_body( $response ) );
        // Сохраняем результат в кеш на 15 минут (900 секунд)
        set_transient( $cache_key, $posts, 900 );
    }
}

// Теперь безопасно выводим $posts

Совет: Чтобы кеш на стороне источника инвалидировался вовремя, используйте хук save_post для сброса кеша при любом сохранении статьи в админке.

Итог: когда REST API НЕ нужен?

Если вам нужно передавать данные в реальном времени — например, вы делаете чат, бегущую строку биржевых котировок или лайв-трансляцию. REST API для этого слишком медленный (накладные расходы на HTTP-запросы вас съедят). Тут смотрите в сторону WebSockets или Server-Sent Events.

Но для 90% интеграций (вывод статей, синхронизация каталогов, передача лидов) — REST API идеален. Попробуйте вывести 5 последних постов через fetch на любом HTML-файле. Как только вы почувствуете эту механику, возвращаться к костылям вам больше не захочется.