WP REST API ломается не на endpoint’ах, а на плохой архитектуре контента

WP REST API ломается не на endpoint’ах, а на плохой архитектуре контента

REST API в WordPress часто считают «просто способом отдать JSON», но на практике проблемы начинаются раньше: когда посты, поля и таксономии не продуманы под headless-потребление. Если структура контента хаотична, фронтенд получает слишком много лишних запросов и сложную логику сборки страниц.

Чтобы API работал предсказуемо:
— разделяйте сущности: запись, блок, медиа, навигацию;
— храните в ACF или метаполях только то, что реально нужно фронту;
— сразу определяйте, какие поля должны приходить в одном ответе, а какие — отдельным запросом;
— не полагайтесь на «как-нибудь соберём на клиенте» — это быстро превращается в технический долг.

Отдельно проверьте авторизацию и кэширование. Публичные данные можно отдавать через стандартные endpoints, а для приватных сценариев лучше заранее продумать токены, права пользователей и ограничения на доступ. Иначе API будет либо слишком открытым, либо неудобным для команды.

Ещё одна типовая ошибка — тянуть в REST всё подряд через кастомные запросы без схемы. Такой подход сложно поддерживать: фронтенд привязывается к случайным полям, а любое изменение в WordPress ломает сборку страницы.

Если строите headless на WordPress, проектируйте REST API как контракт между CMS и фронтом: меньше случайных полей, больше понятных сущностей и стабильных ответов.