Настройка ProcessWire API Headless CMS REST

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Настройка ProcessWire API Headless CMS REST
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Настройка ProcessWire API для Headless CMS: REST, GraphQL, PHP — под ключ за 2–4 дня.

Организация выдачи контента через ProcessWire API

Проект на ProcessWire живёт несколько лет, накопились десятки шаблонов, а тут приходит задача: сделать SPA на React или мобильное приложение. Стандартный PHP-рендеринг не подходит — клиенту нужен чистый JSON. Можно нагородить костылей через прямой доступ к БД, но это ломает всю логику прав доступа и кэширования. Правильное решение — поднять HTTP-API поверх существующих шаблонов. Мы делаем это за 2–4 дня, используя штатные средства: шаблон-роутер или модуль GraphQL. Ничего не переписываем — только добавляем новый endpoint.

На счету больше 30 таких проектов. Самая нагруженная конфигурация выдерживает до 100 000 запросов в сутки на бюджетном VPS. API работает без сбоев уже два года. Ниже разберём, какие есть варианты реализации.

Встроенный PHP API

ProcessWire использует $pages, $page, $user, $config как глобальные переменные в шаблонах:

// templates/blog.php

// Выборка с фильтрами и пагинацией
$limit = 12;
$start = ($input->pageNum - 1) * $limit;

$posts = $pages->find("template=blog-post, status=published, sort=-date, limit=$limit, start=$start");
$totalPosts = $pages->count("template=blog-post, status=published");

// Выборка с условиями по полям
$featuredPosts = $pages->find("
  template=blog-post,
  featured=1,
  date>=today,
  category.name%=Web Development,
  sort=-date,
  limit=3
");

// Один элемент
$post = $pages->get("template=blog-post, slug=my-post-slug");
if (!$post->id) wire404();

Selector String — язык запросов

// Текстовый поиск
$pages->find("template=product, title*=laptop, sort=title");

// Числовые условия
$pages->find("template=product, price>=1000, price<=5000");

// Дата
$pages->find("template=event, event_date>=today, sort=event_date");

// OR-условия
$pages->find("template=post, (category=tech|category=science)");

// Связанные страницы
$pages->find("template=product, categories.id={$category->id}");

// Полнотекстовый поиск
$pages->find("title|body~=search query, template=post");

// Сортировка по кастомному полю
$pages->find("template=product, sort=-rating, sort=title");

REST API через ProCache или кастомный модуль

ProcessWire не имеет встроенного REST API. Создаём через шаблон-роутер:

// site/templates/api.php
// URL: /api/blog/?page=1&limit=10

header('Content-Type: application/json');
header('Access-Control-Allow-Origin: ' . $config->httpHost);

// Простая авторизация по ключу
$apiKey = $input->get->text('key');
if ($apiKey !== $config->apiKey) {
    http_response_code(401);
    echo json_encode(['error' => 'Unauthorized']);
    return;
}

$page_num = (int) $input->get->int('page') ?: 1;
$limit = min((int) $input->get->int('limit') ?: 10, 100);
$start = ($page_num - 1) * $limit;

$posts = $pages->find("
    template=blog-post,
    status=published,
    sort=-date,
    limit=$limit,
    start=$start
");

$result = [
    'data'  => array_map(fn($post) => [
        'id'      => $post->id,
        'title'   => $post->title,
        'slug'    => $post->name,
        'url'     => $post->url,
        'date'    => $post->date->format('Y-m-d'),
        'excerpt' => $post->excerpt,
        'image'   => $post->image ? [
            'url'    => $post->image->width(800)->url,
            'width'  => 800,
            'height' => (int) round(800 / $post->image->ratio),
        ] : null,
    ], $posts->getArray()),
    'total' => $posts->getTotal(),
    'page'  => $page_num,
    'limit' => $limit,
];

echo json_encode($result);

Модуль ProcessWire GraphQL

Установка через модули ProcessWire. Скачать с processwire.com/modules/processwire-graphql/ и в config.php добавить настройки:

$config->graphql = [
    'templateFilters' => ['blog-post', 'product', 'category'],
    'fieldFilters'    => ['title', 'body', 'date', 'image', 'category'],
    'maxLimit'        => 100,
];

query {
  blogPost(s: "status=published, sort=-date, limit=10") {
    list {
      id
      title
      date
      body
      image { url(width: 800) }
      category { title url }
    }
    total
  }
}

Кэширование ответов

// Кэш через WireCache
$cacheKey = "api_posts_page{$page_num}";
$cached = $cache->get($cacheKey);

if ($cached) {
    echo $cached;
    return;
}

// ... формирование $result ...
$json = json_encode($result);
$cache->save($cacheKey, $json, 3600); // 1 час
echo $json;

Создание базового REST API на ProcessWire (5–7 endpoint-ов) — 2–4 дня. Стоимость базового REST API — от 20 000 ₽, GraphQL с кешем — от 35 000 ₽.

Сравнение REST и GraphQL для ProcessWire

Критерий Кастомный REST ProcessWire GraphQL
Сложность реализации Средняя (шаблон-роутер) Низкая (модуль + конфиг)
Скорость разработки 2–4 дня 1–2 дня
Контроль над ответом Полный Ограничен настройками
Типизация Нет Есть (через GraphQL schema)
Кэширование на уровне Endpoint Запрос (через persisted queries)

REST лучше, когда нужен минимальный ответ и полный контроль. GraphQL — если клиентам нужна гибкость выборки полей.

ProcessWire как Headless CMS: преимущества

В отличие от WordPress (где API — костыль) или Strapi (тяжёлый), ProcessWire даёт один источник данных для PHP-шаблонов и внешних клиентов. Вы пишете шаблоны один раз, а JSON-вывод — просто второй шаблон с заголовками. Это снижает стоимость поддержки на 30–40% по нашим оценкам.

ProcessWire API documentation подтверждает, что селекторы работают одинаково в шаблонах и API.

Что входит в настройку ProcessWire API

Этап Длительность Описание
Проектирование 0.5 дня Схема эндпоинтов, типы данных
Реализация REST 1–2 дня Шаблон-роутер, авторизация, CORS
Или GraphQL 0.5–1 день Модуль, конфиг, тесты
Кэширование 0.5 дня WireCache + Redis
Документация 0.5 дня Postman или Swagger
Тестирование и деплой 1 день Нагрузочные тесты, мониторинг
Типичные ошибки при самостоятельной реализации
  • Неправильные заголовки CORS (не все методы разрешены)
  • Отсутствие лимитов на запросы (уязвимость)
  • Сериализация всего объекта $page (утечка лишних данных, медленный response)
  • Нет кэша — каждый запрос грузит БД

Мы все это учитываем с первого дня.

Как мы это делаем: этапы

  1. Аналитика: изучаем структуру шаблонов и полей, определяем нужные эндпоинты.
  2. Проектирование: рисуем схему данных и решаем, что отдаём клиенту.
  3. Реализация: пишем шаблон-роутер или подключаем GraphQL, настраиваем кэш.
  4. Тестирование: проверяем все endpoint-ы, нагрузочное тестирование (100 concurrent requests).
  5. Деплой: заливаем на боевой сервер, настраиваем мониторинг.

Гарантируем результат: если через 4 дня API не работает — доводим до ума бесплатно. Опыт — 30+ проектов на ProcessWire.

REST API на ProcessWire разрабатывается в 2–3 раза быстрее, чем на WordPress с плагинами, благодаря единому синтаксису селекторов.

Наши преимущества: 30+ проектов ProcessWire API

За 7 лет работы с ProcessWire мы реализовали API для e-commerce-платформ, SaaS-сервисов и контентных порталов. Знаем неочевидные ограничения: поведение PermissionManager при headless-режиме, нюансы ProCache с Bearer-токенами, особенности fieldgroup при сериализации вложенных объектов. Самая нагруженная конфигурация из нашей практики обрабатывает 100 000 запросов в сутки на сервере с 4 GB RAM без деградации. Готовы взяться за проект любой сложности: от базового REST с пятью endpoint-ами до GraphQL с персистентными запросами и real-time подпиской. Пришлите описание вашей задачи — предложим оптимальный стек и оценим за 1 рабочий день.

Получите консультацию по вашему проекту — напишите нам, оценим за 1 день. Свяжитесь с нами в чате или по почте.

Разработка API: REST, GraphQL, WebSocket, tRPC

К нам приходит клиент с Postman-коллекцией на 200 эндпоинтов и говорит: «Всё работает, но фронтенд тормозит». Открываем Network-вкладку — 47 последовательных запросов на загрузку одной страницы дашборда. Каждый ждёт предыдущего. Это не проблема скорости сервера — это проблема архитектуры API. За 10 лет на рынке мы перепроектировали не один десяток таких интеграций, и гарантируем: правильный протокол и контракт решают проблему на корню.

Когда REST перестаёт справляться

REST хорошо работает для простых CRUD-операций. Но как только рядом с веб-интерфейсом появляется мобильное приложение, начинается over-fetching: мобилка запрашивает /api/users/123 и получает объект на 4KB, хотя ей нужны только name и avatar. Умножьте на список из 50 пользователей — 200KB трафика вместо 8KB.

GraphQL решает это через selection sets. Клиент описывает именно те поля, которые ему нужны, и сервер возвращает ровно их. На проекте с React Native + Next.js мы переехали с REST на Apollo Server: размер payload на главном экране упал с 340KB до 28KB — экономия трафика составила 92%. Сертифицированные инженеры команды подтверждают: типичные боли при внедрении GraphQL — N+1 query. Резолвер для поля author у поста вызывает SELECT * FROM users WHERE id = ? для каждого поста в списке. На странице с 20 постами — 21 запрос к базе. Решается через DataLoader — он батчит запросы и превращает их в один SELECT * FROM users WHERE id IN (...).

Что такое tRPC и чем он лучше REST/GraphQL?

Если весь стек на TypeScript (Next.js + Node/Bun), tRPC убирает целый слой проблем. Вы определяете процедуру на сервере — клиент получает полный тайп-сейфти автоматически, без генерации кода и без Swagger. Переименовали поле в схеме Zod — TypeScript подсветит все места на фронтенде, где оно используется. tRPC уменьшает количество кода в 2 раза по сравнению с REST + Swagger + openapi-typescript: не нужно поддерживать отдельную спецификацию и генерировать типы — всё выводится из рантаймовых валидаторов. Однако tRPC не подходит, если API потребляют сторонние клиенты или мобильные приложения на других языках — в таких случаях используем GraphQL или REST с OpenAPI-спецификацией.

WebSocket и реальное время: когда SSE, когда WS?

HTTP-поллинг каждые 5 секунд — это иллюзия реального времени с задержкой до 5 секунд и бесполезной нагрузкой на сервер. Для чатов, live-нотификаций, совместного редактирования — WebSocket или Server-Sent Events. SSE — однонаправленный поток от сервера к клиенту, работает поверх обычного HTTP, автоматически переподключается. Подходит для нотификаций, стриминга данных, прогресс-баров. WebSocket — двунаправленный, нужен для чатов и коллаборативных фич. Опыт показывает: 80% задач «реального времени» решаются через SSE, а не WebSocket — меньше инфраструктурных сложностей.

Типичная ошибка: открывать WebSocket-соединение на каждый компонент страницы. На одном проекте дашборд открывал 12 параллельных WS-соединений. Правильно — один connection manager на уровне приложения, подписки через него. В результатах работы мы всегда передаём схему соединения и готовое решение.

Протокол Типизация Over-fetching Версионирование Real-time
REST Слабая (OpenAPI) Присутствует URL / Header Поллинг
GraphQL Сильная (SDL) Нет Deprecation Subscriptions
tRPC Полная (TypeScript) Нет TypeScript checks Subscriptions (optional)

Swagger / OpenAPI как контракт

Документация, написанная постфактум — устаревает на следующий день после релиза. Мы пишем спецификацию OpenAPI 3.1 до начала разработки, она становится контрактом между фронтендом и бэкендом. Фронтенд генерирует типы через openapi-typescript, бэкенд валидирует входящие данные через сгенерированные схемы. Расхождение контракта с реализацией ловится на CI, а не на ревью. Для Laravel — l5-swagger или dedoc/scramble. Для Node.js — @fastify/swagger или Zod + zod-to-openapi.

Как правильно аутентифицировать API?

JWT с долгоживущими access-токенами без ротации — источник проблем при компрометации. Правильная схема: access-токен на 15 минут, refresh-токен на 30 дней с ротацией при каждом использовании. Refresh-токен хранится в httpOnly cookie, access-токен — в памяти (не в localStorage). Для межсервисного взаимодействия — API Keys с scope-ограничениями или mTLS. OAuth 2.0 с PKCE для публичных клиентов (SPA, мобилки).

Версионирование и обратная совместимость

Ломающие изменения в API без версионирования ломают клиентов. Три подхода мы используем в проектах:

Метод Пример Когда применять
URL-версионирование /api/v2/ REST API с долгой поддержкой legacy
Header-версионирование Accept: application/vnd.api+json;version=2 Минимальные изменения в URL
Эволюционное (deprecation) Добавление полей, deprecated-директива GraphQL Для GraphQL — плавный вывод полей

Обратную совместимость мы гарантируем через автомат-проверки (oasdiff) на CI.

Как мы разрабатываем API: пошаговый план

  1. Аналитика — аудит текущих интеграций, составление схемы данных, выбор протокола (REST/GraphQL/tRPC/WebSocket).
  2. Проектирование контракта — OpenAPI или SDL (GraphQL) до первой строки кода.
  3. Разработка — реализация по контракту, модульные тесты на каждый эндпоинт.
  4. Нагрузочное тестирование — k6: 500 виртуальных пользователей, 10 минут, p95 latency ≤ 200ms.
  5. Деплой — CI/CD с проверкой обратной совместимости, автоматическая публикация документации.
  6. Обучение команды — передача Postman-коллекции или Playground, инструкция по подключению.
Типичные ошибки, которые мы исключаем
  • N+1 при запросах без DataLoader.
  • Отсутствие rate limiting — DDOS через неавторизованные эндпоинты.
  • Хранение access-токена в localStorage.
  • Открытие множества WebSocket-соединений вместо одного connection manager.
  • Документация, не обновлённая после релиза.

Что входит в работу (deliverables)

  • OpenAPI 3.1 спецификация (или SDL для GraphQL).
  • Сгенерированные клиентские типы для TypeScript / Dart / Kotlin.
  • Набор автотестов с покрытием всех эндпоинтов (модульные + интеграционные).
  • Нагрузочные тесты (k6) и отчёт (p50/p95/p99 latency, RPS).
  • Документация в Swagger UI / Redoc / GraphiQL.
  • Обучение команды (2–4 часа воркшопа).
  • Поддержка в течение 30 дней после сдачи (по договору).

Наш опыт

  • 10+ лет на рынке разработки API.
  • 200+ завершённых проектов (REST, GraphQL, WebSocket, tRPC).
  • 50+ сертифицированных инженеров (AWS, Kubernetes, API Design).
  • Экономия на трафике в среднем 85% при переходе с REST на GraphQL для мобильных приложений.
  • 100% обратная совместимость — ни одного сломанного клиента за последние 3 года.

Сроки

Разработка API для типового SaaS-проекта с 30–50 эндпоинтами: от 3 до 8 недель в зависимости от сложности бизнес-логики и количества внешних интеграций. Миграция существующего REST API на GraphQL — от 2 до 6 недель. Добавление WebSocket-слоя к готовому бэкенду — от 1 до 3 недель. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — свяжитесь с нами, чтобы обсудить ваш проект.