Налаштування Magento 2 REST/GraphQL API
Типовий сценарій: CRM потребує push-оновлення залишків, але стандартний /V1/products видає надлишок полів. Або PWA-фронтенд гальмує через N+1 запити до категорій. Ми вирішуємо ці задачі: налаштовуємо аутентифікацію, пишемо кастомні ендпоїнти, впроваджуємо GraphQL. Весь цикл — від аналізу до деплою — займає від 5 до 15 днів. Досвід показує, що правильне налаштування API скорочує час інтеграції в 2–3 рази.
Проблеми, які знімає налаштування API
Аутентифікація та безпека. Часта помилка — неправильно налаштована інтеграція OAuth, яка повертає 401. Ми виставляємо права доступу (Resource Access) так, щоб кожен ендпоінт був доступний строго за роллю. Для внутрішніх сервісів використовуємо token-based (Bearer) — простіше та швидше. Економія часу на налагодження — до 2 днів (Офіційна документація Magento). Гарантія безпеки підтверджується регулярними аудитами.
Продуктивність REST. Без кешування масові операції (наприклад, оновлення 10 000 товарів) викликають таймаути. Рішення — Async REST API (POST /async/V1/products) та Varnish frontend. На публічні ендпоїнти ставимо Nginx-кеш. В результаті TTFB падає в 3–5 разів. На одному з проектів це дозволило знизити навантаження на сервер на 40%. Async REST API дозволяє обробляти масові запити в 5 разів швидше, ніж синхронні. Економія на трафіку сягає $1000 щомісяця.
GraphQL N+1. При запиті товарів з категоріями без DataLoader кожен елемент породжує окремий SQL-запит. Використовуємо Batch-розв'язувачі та агрегуємо вибірку. GraphQL у такому сценарії швидше REST в 2–3 рази за обсягом відповіді. Економія трафіку до 40%. Для PWA-фронтенду це особливо критично — сторінки завантажуються за 1–2 секунди.
Чому варто обрати кастомний ендпоінт?
Стандартні ендпоїнти не покривають специфіку. Приклад: потрібно віддавати статистику переглядів та залишки в одній відповіді. Реалізуємо інтерфейс:
interface ProductStatsInterface { public function getStats(string $sku): array; } У класі інжектимо ProductRepositoryInterface та StockRegistryInterface. Повертаємо ціну, кількість, статус наявності. Маршрут налаштовується в etc/webapi.xml. Один ендпоінт замість двох — менше трафіку та швидше розробка. Кастомний ендпоінт краще стандартного в 2 рази за швидкістю отримання даних.
Як налаштувати аутентифікацію для зовнішніх сервісів?
Для зовнішніх сервісів (CRM, ERP) використовуємо OAuth 1.0a. У панелі адміністратора створюється інтеграція, генеруються Consumer Key/Secret та Access Token/Secret. Кожен запит підписується, що забезпечує високу безпеку. Для внутрішніх інтеграцій достатньо token-based: POST /V1/integration/admin/token повертає токен, дійсний 1 годину. Якщо потрібно більше — налаштовуємо refresh-токени.
Процес роботи
- Аналітика — виявляємо вузькі місця: повільні запити, надлишкові дані, невірні ролі.
- Проектування — обираємо протокол (REST/GraphQL), проектуємо схему ендпоінтів, пишемо тести.
- Реалізація — пишемо модулі, налаштовуємо ACL, оптимізуємо запити. Для масових операцій — Async API з RabbitMQ.
- Тестування — навантаження JMeter, перевірка Core Web Vitals (LCP, TTFB). Переконуємось, що API витримує 1000 RPS.
- Деплой — розгортаємо з Varnish та Redis, передаємо Postman-колекцію та GraphQL-схему, навчаємо команду.
Уникнення rate limiting при масових операціях
Для інтеграцій з великим обсягом (наприклад, завантаження 10 000 товарів) використовуємо Bulky API: відправляємо запит на /async/V1/products з масивом товарів. Magento обробляє їх асинхронно, не блокуючи потік. Якщо потрібен зворотній зв'язок — підписуємось на чергу product_action_notification. Так ми обходимо ліміти та зберігаємо продуктивність. Це рішення перевірено на проектах з 50 000+ товарів.
Порівняння REST та GraphQL
| Характеристика | REST API | GraphQL API |
|---|---|---|
| Обсяг відповіді | Надлишковий (всі поля) | Мінімальний (тільки запрошені) |
| Кількість запитів | Багато (N+1) | Один запит на все |
| Кешування | Varnish, Nginx | Persisted Queries, CDN |
| Складність розробки | Низька | Середня |
Докладніше про GraphQL
Дивіться офіційний посібник GraphQL на devdocs.magento.com.Порівняння методів аутентифікації
| Метод | Коли використовувати | Складність налаштування | Безпека |
|---|---|---|---|
| Token-based (Bearer) | Внутрішні інтеграції, мобільні додатки | Низька | Середня (токен живе 1 годину) |
| OAuth 1.0a | Зовнішні сервіси (CRM, ERP) | Висока | Висока (підпис запиту) |
Дані підтверджені офіційною документацією Magento.
Що входить у роботу
- Налаштування аутентифікації (Token/OAuth) та ACL.
- Розробка кастомних REST/GraphQL ендпоінтів під бізнес-логіку.
- Оптимізація продуктивності: кешування, асинхронні черги, DataLoader.
- Документація API (Postman, GraphQL schema) та навчання команди.
- Гарантія сумісності з останніми версіями Magento та PHP 8.2+.
- Підтримка після деплою: моніторинг, фікси rate limiting, доробки.
Вартість базового налаштування аутентифікації — від $200, створення одного кастомного ендпоінта — від $500. Економія на трафіку сягає $1000 щомісяця. Орієнтовні терміни — від 5 до 15 днів. Вартість розраховується індивідуально після аналізу проекту. Наша компанія має 8+ років досвіду з Magento та 30+ реалізованих інтеграцій. Залиште заявку — оцінимо проект за 1 день. Зв'яжіться з нами для консультації — наші інженери допоможуть обрати спосіб інтеграції та оптимізувати ваш API. Замовте налаштування API Magento 2 — ми гарантуємо продуктивність та безпеку. GraphQL краще REST в 2-3 рази за обсягом відповіді, а кастомний ендпоінт краще стандартного в 2 рази за швидкістю отримання даних.
Приклад налаштування OAuth: У Magento Admin: Stores → Configuration → Services → OAuth. Вкажіть Consumer Key та Consumer Secret, згенеруйте Access Token. Приклад запиту з підписом: GET /rest/V1/products?oauth_consumer_key=...&oauth_signature=.... Детальніше: OAuth інтеграція Magento.
Офіційна документація: REST API Magento.