WordPress API: как работает REST API и с чего начать

У каждого сайта на WordPress есть встроенный программный интерфейс — «дверь», через которую другие программы могут читать и менять контент, не открывая админку. Мобильное приложение, связка с CRM, скрипт автопубликации и даже ИИ-агент говорят с сайтом одним языком — через REST API. Разбираемся, как он устроен, как посмотреть его на своём сайте и что важно знать про безопасность.

Что такое REST API простыми словами

REST (Representational State Transfer — «передача репрезентативного состояния») — архитектурный стиль, при котором программы обмениваются данными по обычному HTTP — тому же протоколу, по которому браузер открывает страницы. Ответы приходят в формате JSON (JavaScript Object Notation) — компактном текстовом формате «ключ: значение», который понимает любой язык программирования.

Логика повторяет работу с базой данных: методом GET данные читают, POST — создают, PUT или PATCH — обновляют, DELETE — удаляют. Каждый «адрес» в API называется эндпоинтом (конечной точкой): /wp-json/wp/v2/posts отвечает за записи, /wp-json/wp/v2/pages — за страницы, /wp-json/wp/v2/media — за медиафайлы.

Как посмотреть API своего сайта

Включать ничего не нужно: REST API работает из коробки начиная с WordPress 4.7. Откройте в браузере адрес https://ваш-сайт.ру/wp-json/ — увидите JSON-описание всех возможностей: пространства имён (namespaces), маршруты (routes) и их аргументы. API самодокументирован: по этому индексу можно понять, что сайт умеет, без отдельной документации.

Практический пример — получить последние десять записей:

curl https://ваш-сайт.ру/wp-json/wp/v2/posts?per_page=10

В ответе придёт массив JSON-объектов с заголовком, содержимым, датой и служебными ссылками. Полезные детали: общее число записей приходит в заголовке ответа X-WP-Total, а связанные данные (картинка записи, автор) — в блоке _embedded, если добавить параметр ?_embed. Постраничная навигация — параметры page и per_page.

Аутентификация: от анонимного чтения к паролю приложения

Без авторизации API отдаёт только публичное: опубликованные записи, страницы, открытые данные. Создание, правки, черновики и настройки требуют аутентификации. Основные способы:

• Пароль приложения (Application Passwords) — штатный механизм с WordPress 5.6. Создаётся в профиле пользователя («Пользователи → Профиль → Пароли приложений»), работает по стандартной Basic-аутентификации поверх HTTPS и подходит для скриптов и интеграций.
• Cookie + nonce — для JavaScript, который работает на самом сайте (тема или плагин): браузер уже авторизован, а одноразовый токен nonce защищает запрос от подделки.
• JWT и OAuth — через плагины, когда внешнему приложению нужен временный токен вместо хранения пароля.

Важно: пароль приложения наследует права пользователя, которому принадлежит. Для интеграции заведите отдельную учётную запись с минимально необходимой ролью — например, «автора», если интеграция только публикует материалы.

Свой эндпоинт: register_rest_route

Когда стандартных маршрутов мало, плагин или тема регистрирует свой — функцией register_rest_route(). Минимальный рабочий пример:

add_action( 'rest_api_init', function () {
    register_rest_route( 'myplugin/v1', '/stats', [
        'methods'             => 'GET',
        'permission_callback' => '__return_true',
        'callback'            => function () {
            return rest_ensure_response( [
                'posts' => wp_count_posts()->publish,
            ] );
        },
    ] );
} );

Маршрут станет доступен по адресу /wp-json/myplugin/v1/stats. Самая важная строка — permission_callback: именно она решает, кому можно вызывать эндпоинт. Начиная с WordPress 5.5 регистрация маршрута без этого параметра вызывает предупреждение, а «забытая» проверка прав — самая частая дыра самодельных API. Если эндпоинт публичный, напишите __return_true явно; если только для админов — проверяйте current_user_can().

Что реально автоматизируют через WordPress API

Классические сценарии: автопубликация из внешней системы (генератор описаний товаров пишет материалы напрямую в API), синхронизация магазина с 1С или складским сервисом, мобильные приложения и headless-архитектура, где WordPress работает бэкендом, а фронтенд собран отдельно — например, на Next.js.

WooCommerce добавляет собственное пространство имён /wc/v3: товары, заказы и купоны доступны теми же методами GET и POST. Как магазин живёт под капотом, мы разбирали в статье про хуки WooCommerce.

Новое поколение потребителей API — ИИ-агенты: WordPress 7 получил встроенный AI Client, а агентские шлюзы вроде MCP подключаются к сайту тоже поверх его API. Как это выглядит на практике для магазина — в нашем материале «MCP для WooCommerce: даём ИИ доступ к магазину». Если удобнее управлять сайтом из терминала без HTTP-запросов — те же операции с контентом умеет делать WP-CLI.

Безопасность: что проверять в первую очередь

REST API — это дверь, и относиться к ней стоит по-дверному:

• Обновляйте ядро. Летом 2026 исследователи показали атаку wp2shell: через batch-эндпоинт /wp-json/batch/v1 на необновлённых сайтах можно было добраться до SQL-инъекции и даже выполнения кода. Свежий пример из того же сезона — критическая уязвимость CVE-2026-87902 в ядре WordPress.
• Минимальные права. Отдельный пользователь для интеграции, роль не выше необходимой; пароли приложений отзываются на том же экране, где создаются.
• HTTPS обязателен. Пароль приложения в Basic-аутентификации передаётся в каждом запросе, и без шифрования его видно в открытом виде.
• Логи. Подозрительные серии POST-запросов к /wp-json/ хорошо видны в логах WordPress; общий чек-лист защиты — в нашем гайде по безопасности WordPress.

Когда REST API не нужен

Если задача — разово поправить текст или виджет, админка быстрее и безопаснее. Серверные операции — обновления, поиск-замена, массовый импорт — удобнее делать через WP-CLI: он вызывает те же функции ядра, но без сети и лимитов HTTP. REST API выигрывает, когда с сайтом говорит другая система: приложение, внешний сервис, конвейер контента или ИИ-агент.

Начните с малого: откройте /wp-json/ своего сайта, сделайте curl-запрос списка записей, создайте пароль приложения и опубликуйте черновик из скрипта. Это час практики, после которого архитектура API перестаёт быть абстракцией.