<b>WP REST API ломает не WordPress, а слабую схему данных и авторизацию</b>

<b>WP REST API ломает не WordPress, а слабую схему данных и авторизацию</b>

WP REST API — это не “ещё один способ отдать посты”, а нормальный контракт между WordPress и фронтендом. Если строите headless-проект, сразу разделяйте: публичные данные, защищённые данные и служебные поля. Иначе фронт начнёт зависеть от всего подряд, а бэкенд — превращаться в свалку кастомных endpoint’ов.

Чтобы не получить хаос, держите базовый чек-лист:
• используйте стандартные маршруты для постов, страниц, таксономий;
• для кастомных сущностей делайте свои endpoint’ы, а не расширяйте один универсальный;
• скрывайте лишние поля через prepare_callback или filters;
• не отдавайте в ответе то, что не нужно рендерить на клиенте.

Частая ошибка — пытаться через REST решить всё: и выдачу контента, и бизнес-логику, и контроль доступа. На практике лучше, когда API возвращает чистые данные, а сложные проверки остаются на сервере. Тогда проще кешировать ответы, тестировать запросы и менять фронтенд без переписывания WordPress.

Ещё один важный момент — стабильность схемы. Если поле уже используется на фронте, не переименовывайте его без переходного слоя. Добавляйте новые поля, а старые убирайте только после миграции. Так API остаётся предсказуемым, а headless-сборка не разваливается от мелкого рефакторинга.

Начинайте с понятного контракта и минимального набора endpoint’ов: это дешевле, чем потом чинить API, который вырос без правил.