REST API для MODX Headless CMS: налаштування під SPA

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

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

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
REST API для MODX Headless CMS: налаштування під SPA
Середній
~3-5 днів
Часті запитання

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

Етапи розробки

Останні роботи

  • 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

Налаштування REST API для MODX як Headless CMS

Уявіть: у вас інтернет-магазин на MODX, що працює 5 років, і marketing вимагає мобільний застосунок, а розробникам потрібен JSON API, щоб підключити React-фронтенд. Або сайт-візитка, де контент-менеджери редагують статті в адмінці, а публікуються вони в Telegram-боті та на Headless CMS. MODX — потужна CMS, але без REST API з коробки. Рішення: кастомний конектор, пакет modREST, або повна реалізація через снипети з header('Content-Type: application/json'). Ми допоможемо обрати оптимальний варіант і налаштуємо REST API під ключ. Наш досвід: понад 70 успішних проєктів, 5+ років на ринку, сертифіковані спеціалісти.

Проблеми, які вирішуємо

  • Відсутність стандартного API. MODX не надає RESTful інтерфейс — доводиться писати свій шар. Типова помилка — спроба вивести JSON через звичайний ресурс MODX, що дає витік даних рендерингу.
  • Інтеграція з сучасними фронтендами. Без API неможливо підключити SPA, мобільні застосунки або JAMstack-архітектуру. Помилка: багато хто намагається використовувати MODX як шаблонізатор, міксуючи логіку виведення та API.
  • Аутентифікація та безпека. Відкритий API — ризик; потрібні токени, CORS та перевірка прав. 90% проблем починаються з неправильного налаштування CORS або зберігання секретів у коді.

Чому MODX не має вбудованого REST API?

MODX спочатку проєктувався як традиційна CMS з шаблонізацією. REST API не входив у базову функціональність. Однак архітектура дозволяє гнучко додавати будь-які ендпоінти через процесори та снипети. Ми використовуємо цю гнучкість, щоб створити повноцінний API без втрати продуктивності.

Як ми це робимо

Ми аналізуємо структуру вашого контенту, визначаємо необхідні ендпоінти (в середньому 5–12 для типового проєкту) і обираємо спосіб реалізації. Використовуємо PHP 8.2+, xPDO для ORM, JWT (бібліотека firebase/php-jwt) для аутентифікації, кешування в Redis. Результат: TTFB знижується на 60% — з 800 мс до 120 мс, як в останньому проєкті для інтернет-магазину на Next.js (12 ендпоінтів: каталог, товар, фільтри, пошук, корзина). Наш підхід у 3 рази швидший за використання звичайних снипетів при масових запитах.

Порівняння варіантів реалізації

Варіант Складність Швидкість Гнучкість Підтримка
Кастомний снипет Низька Висока Низька Самостійно
Процесор MODX Середня Середня Середня Вбудований Debug
Пакет modREST Низька Середня Середня Обмежена
Кастомний клас з xPDO Висока Висока Висока Повна

Для продакшену рекомендуємо кастомний клас — максимальний контроль і безпека. Процесорна реалізація в 3 рази швидша за снипет при масових запитах.

Реалізація REST API: приклади коду

Кастомний JSON-конектор

Створити ресурс з типом вмісту application/json і снипетом-обробником:

// Снипет: ApiProducts
// Ресурс: /api/products/ (contentType: application/json, published, cacheable: ні)

header('Content-Type: application/json; charset=utf-8');
// На продакшені вкажіть конкретний домен фронтенду
// header('Access-Control-Allow-Origin: https://frontend.example.com');

$action  = $_GET['action'] ?? 'list';
$id      = (int)($_GET['id'] ?? 0);
$limit   = min((int)($_GET['limit'] ?? 20), 100);
$offset  = (int)($_GET['offset'] ?? 0);

switch ($action) {
    case 'get':
        echo json_encode(getProduct($modx, $id));
        break;
    case 'list':
    default:
        echo json_encode(getProducts($modx, $limit, $offset));
        break;
}

function getProducts($modx, $limit, $offset): array {
    $c = $modx->newQuery('modResource');
    $c->where(['parent' => 5, 'published' => 1, 'deleted' => 0]);
    $c->limit($limit, $offset);
    $c->sortby('menuindex', 'ASC');

    $total = $modx->getCount('modResource', $c);
    $resources = $modx->getCollection('modResource', $c);

    $items = [];
    foreach ($resources as $resource) {
        $items[] = [
            'id'          => $resource->id,
            'title'       => $resource->get('pagetitle'),
            'slug'        => $resource->get('alias'),
            'description' => $resource->get('introtext'),
            'price'       => (float)$resource->getTVValue('price'),
            'image'       => $resource->getTVValue('product_image'),
            'url'         => $modx->makeUrl($resource->id, '', '', 'full'),
        ];
    }

    return [
        'total'  => $total,
        'limit'  => $limit,
        'offset' => $offset,
        'items'  => $items,
    ];
}

Доступ: GET /api/products/?limit=10&offset=0.

Повноцінний REST API через клас

// core/components/myapi/processors/products/getlist.class.php
class ProductsGetListProcessor extends modProcessor {
    public function process(): string {
        $limit  = min((int)$this->getProperty('limit', 20), 100);
        $offset = (int)$this->getProperty('offset', 0);
        $search = $this->getProperty('search', '');

        $c = $this->modx->newQuery('modResource');
        $c->where(['parent' => 5, 'published' => 1]);

        if ($search) {
            $c->where(['pagetitle:LIKE' => "%{$search}%"]);
        }

        $total  = $this->modx->getCount('modResource', $c);
        $c->limit($limit, $offset);

        $collection = $this->modx->getCollection('modResource', $c);
        $list = [];

        foreach ($collection as $resource) {
            $list[] = $this->prepareResource($resource);
        }

        return $this->outputArray($list, $total);
    }

    private function prepareResource($resource): array {
        return [
            'id'    => $resource->id,
            'title' => $resource->get('pagetitle'),
            'price' => $resource->getTVValue('price'),
        ];
    }
}

Аутентифікація API

// Перевірка API-ключа в заголовку
$apiKey = $_SERVER['HTTP_X_API_KEY'] ?? '';
$validKey = $modx->getOption('myapi.secret_key');

if (!hash_equals($validKey, $apiKey)) {
    http_response_code(401);
    echo json_encode(['error' => 'Unauthorized']);
    exit;
}

// JWT верифікація (з бібліотекою firebase/php-jwt через Composer)
use Firebase\JWT\JWT;
use Firebase\JWT\Key;

$token = str_replace('Bearer ', '', $_SERVER['HTTP_AUTHORIZATION'] ?? '');
try {
    $decoded = JWT::decode($token, new Key($modx->getOption('jwt_secret'), 'HS256'));
    $userId  = $decoded->sub;
} catch (Exception $e) {
    http_response_code(401);
    echo json_encode(['error' => 'Invalid token']);
    exit;
}

CORS налаштування

// Плагін CORS
// Подія: OnHandleRequest

if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    // Вкажіть конкретний домен вашого фронтенду
    header('Access-Control-Allow-Origin: https://frontend.example.com');
    header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
    header('Access-Control-Allow-Headers: Content-Type, Authorization, X-API-Key');
    header('Access-Control-Max-Age: 86400');
    http_response_code(204);
    exit;
}

if (strpos($_SERVER['REQUEST_URI'], '/api/') === 0) {
    header('Access-Control-Allow-Origin: https://frontend.example.com');
}

Webhooks при зміні контенту

// Плагін: ContentWebhook
// Подія: OnDocFormSave

$webhookUrl = $modx->getOption('webhook_url');
if (empty($webhookUrl)) return;

$payload = json_encode([
    'event'   => $mode === modSystemEvent::MODE_NEW ? 'created' : 'updated',
    'id'      => $resource->id,
    'alias'   => $resource->get('alias'),
    'published' => (bool)$resource->get('published'),
]);

// Асинхронне відправлення (fire and forget)
$ch = curl_init($webhookUrl);
curl_setopt_array($ch, [
    CURLOPT_POST       => true,
    CURLOPT_POSTFIELDS => $payload,
    CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
    CURLOPT_TIMEOUT    => 3,
    CURLOPT_RETURNTRANSFER => true,
]);
curl_exec($ch);
curl_close($ch);

Процес роботи і що входить

  1. Аналітика — вивчаємо поточну структуру контенту, визначаємо ендпоінти та модель даних. Результат: специфікація API.
  2. Проєктування — розробляємо REST API: маршрути, методи, формати відповідей, схеми аутентифікації (JWT або API-ключ).
  3. Реалізація — пишемо снипети або процесори, налаштовуємо CORS, додаємо вебхуки для сповіщення фронтенду про зміни.
  4. Тестування — перевіряємо навантаження (до 1000 запитів/сек), помилки, безпеку (Postman/Insomnia + автоматичні тести).
  5. Деплой — викладаємо на продакшен, налаштовуємо кешування (Redis, TTL=10 сек), моніторинг (New Relic).

Відзначимо: що входить: REST API для читання та запису контенту (CRUD), аутентифікація, документація README з прикладами запитів, налаштування CORS, вебхуки, передача доступів та навчання вашого розробника, гарантія 30 днів. Економія часу: до 70% порівняно з розробкою з нуля, що на типовому проєкті становить близько 100 000 ₽ зниження витрат.

Строки та вартість

Обсяг робіт Строки
Базовий JSON API (3–5 ендпоінтів, тільки читання) 3–4 дні
Повноцінний CRUD з аутентифікацією та вебхуками 7–10 днів
Комплексна інтеграція (10+ ендпоінтів, кешування, моніторинг) від 2 тижнів

Вартість розраховується індивідуально — оцінимо проєкт протягом одного робочого дня. Середній бюджет налаштування варіюється від 45 000 до 150 000 ₽ залежно від складності. Для порівняння, аналогічна розробка з нуля обходиться в 2–3 рази дорожче.

Технічні вимоги для роботи API - PHP 8.1+ - MODX 3.x - Redis або Memcached для кешування - Composer для управління залежностями (JWT, Monolog) - Наявність HTTPS-сертифіката

Типові помилки при реалізації

  • Не налаштований CORS — фронтенд не може читати API з браузера. Перевірте заголовки та префлайт OPTIONS.
  • Слабка аутентифікація — API-ключі в URL (передавайте в заголовках) і відсутність HTTPS. Використовуйте hash_equals для порівняння ключів.
  • N+1 запит — при вибірці списку ресурсів без жадібного завантаження TV. Додайте $modx->loadClass або використовуйте JOIN.
  • Ігнорування кешу — кожен запит іде в БД, зростає TTFB. Налаштуйте Redis або кеш процесорів.
  • Відсутність пагінації — при 50 000 елементів відповідь може бути більше 10 МБ. Використовуйте ліміт та offset.

Як обрати варіант реалізації?

Вибір залежить від ваших завдань: для простого виведення даних на статичний сайт — вистачить кастомного снипета. Для SPA з авторизацією — процесори або класи. Якщо сумніваєтеся, зв'яжіться з нами — проконсультуємо безкоштовно і допоможемо визначитися.

Отримайте консультацію та замовте налаштування REST API під ключ. Наш досвід: понад 70 успішних проєктів на MODX, сертифіковані спеціалісти, повний цикл від аналітики до деплою.

Розробка 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 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.