API OpenCart потрібен не заради самого підключення, а для конкретного обміну даними: передати замовлення, отримати залишки або оновити каталог. Надійна інтеграція починається з опису цих дій. Запит, який один раз повернув успішну відповідь, ще не доводить, що система правильно працюватиме після тайм-ауту або повторного запуску.
Визначте контракт та власника кожного поля
Для кожного напряму запишіть джерело, одержувача, ідентифікатор запису та умову оновлення. Наприклад, залишком керує облікова система, а редактор магазину змінює SEO-опис. Якщо обидва процеси перезаписують усе підряд, наступна синхронізація може стерти ручну роботу.
Контракт має пояснювати різницю між відсутнім значенням, порожнім рядком і нулем. Укажіть валюту, одиниці вимірювання, часовий пояс і спосіб позначення видалених позицій. Для товарів з опціями одного артикулу головного товару може бути недостатньо: потрібне стабільне зіставлення варіантів.
Не припускайте, що всі OpenCart API однакові
Маршрути, авторизація та набір доступних операцій залежать від версії й розширення. Штатний API OpenCart 3 не слід вважати універсальним інтерфейсом CRUD для всього каталогу. Спершу перевірте доступні методи, а відсутній сценарій узгодьте як окрему розробку.
У вихідному коді входу API OpenCart 3.0.4.1 передбачено перевірку ключа та дозволеної IP-адреси. Для власного сервісу окремо визначте права й область доступу. Передавайте запити через HTTPS, зберігайте секрети на сервері та не виводьте ключі в журнали. Дані покупців передавайте лише в межах потрібної бізнес-операції.
Повторний запит не повинен створювати друге замовлення
Якщо відповідь не отримано, операція могла вже відбутися. Тому сліпе повторення запису небезпечне. Передбачте зовнішній ідентифікатор замовлення, перевірку дубля та погоджену логіку повтору. Сам ідентифікатор повинен бути унікальним у контексті джерела, а не лише одного поточного пакета.
- Обробляйте дані обмеженими пакетами та зберігайте контрольну точку.
- Розрізняйте помилку валідації, обмеження частоти й тимчасову недоступність.
- Повторюйте операції лише тоді, коли це безпечно за контрактом.
- Після втрати з’єднання перевіряйте стан, а не позначайте всю партію успішною.
Що перевірити під час приймання
Пройдіть створення, оновлення, повторення того самого пакета, обрив посередині та відновлення. Звірте кількість записів і вибіркові значення з джерелом. У журналі достатньо ID операції, часу, типу дії, тривалості та безпечного коду помилки; повні персональні дані там зазвичай не потрібні.
У ShopX розділяйте задачі обміну каталогом і роботи із замовленнями. Допоможе порівняння CRM PRO та Pricer PRO. Якщо готового сценарію немає, опишіть контракт до оцінки кастомної інтеграції — це зменшить кількість неоднозначностей під час розробки.
Джерело для версії 3.0.4.1: контролер входу OpenCart API.
