WP REST API ломает фронт не из-за WordPress, а из-за плохой схемы данных

WP REST API ломает фронт не из-за WordPress, а из-за плохой схемы данных

Если подключаете WordPress как headless CMS, сразу проверьте 4 вещи: — какие поля реально нужны фронту; — какие сущности лучше отдавать отдельными запросами; — где пригодится кастомный endpoint; — какие ответы должны быть кешируемыми.

Не тащите в API весь post object «на всякий случай». Лишние поля замедляют выдачу, усложняют поддержку и заставляют фронтенд зависеть от внутренностей WordPress. Лучше заранее описать контракт: что приходит в списке, что — в карточке, что — только по slug или ID. Это особенно важно для ACF, таксономий и вложенных медиа.

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

И еще: проверяйте ответы REST API как часть проекта, а не как временный мост. Когда контракт стабилен, фронтенд меняется без боли, а WordPress остается надежным источником контента.