Блокування та обмеження Syrve Live API

     Хмарні системи з відкритим API завжди мають обмеження у використанні через необхідність зробити сервіс максимально надійним та стабільним для клієнтів.

     Щоб забезпечити роботу високонавантаженого сервісу, виникає необхідність аналізувати трафік та обмежувати випадки некоректної роботи сервісу.

У Live API є 2 види обмежень на роботу з API:

1. Повне блокування API логіну;
2. Обмеження API логіну по кількості запитів.

     Блокування API логіну

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

Блокування може застосовуватися в таких випадках:

• Масова відправка однакових запитів;
  • зазвичай це пов'язано з тим, що інтеграція не перевіряє відповіді від нашого сервісу;
• Високий відсоток помилкових запитів;
  • помилки інтеграції не виправляються. Особливо це актуально при відправленні запитів на створення замовлення. У такому випадку простіше вимкнути таку інтеграцію, ніж потім розбиратися з такими замовленнями на касі;
• Забагато замовлень;
  • якщо інтеграція створює понад 1000 замовлень на добу для одного закладу, швидше за все, система використовується неправильно;
• пікове навантаження для будь-яких груп методів API;
  • зазвичай через помилки в логіці інтеграції;
• навантажувальне тестування та/або стрес-тестування інтеграції;
  • навантажувальне тестування в середовищі продукту заборонено для будь-яких інтеграцій, тому при виявленні таких інтеграцій система може заблокувати їх назавжди;
• інші випадки
  • Неможливо описати всі варіанти, які можуть призвести до блокування. Однак випадки неналежного використання API регулярно оновлюватимуться.

     Обмеження API логіна за кількістю запитів або «Забагато запитів» (відповідь з кодом 429)

     Це обмеження застосовується до API логіна тільки в тому випадку, якщо інтеграція починає надсилати необґрунтовано велику кількість запитів до однієї групи запитів.

Як це працює:

• Усі методи API поділяються на групи запитів на основі даних, що повертаються;
• Кожен метод входить в одну групу запитів;
• Максимально допустима кількість запитів на один тайм-слот (часовий інтервал) для кожної групи запитів визначається експертом на основі аналізу історії даних. При цьому кількість таких запитів:
  • не залежить від кількості закладів, з котрими працює інтеграція: для методів роботи з довідниками мережі;
  • залежить від кількості закладів з котрими працює інтеграція: для методів роботи із замовленнями, складським списком та іншими даними в залежності від закладу.
• Тайм-слот відрізняється для різних груп методів (зазвичай від 1 до 10 хв)
  • в більшості випадків це 1 хвилина.
• Якщо інтеграція вже виконала максимально допустиму кількість запитів до певної групи методів у поточному тайм-слоті (часовому інтервалі), то поки цей таймс-слот не закінчиться, всі запити до методів групи одразу повертати відповідь з кодом 429.

Приклади груп запитів:

• Довідники (включає всі довідники, отримані для мережі);
• Деталі замовлень (включає весь набір методів, котрі повертають замовлення);
• Інші.

Приклади, коли може застосуватись блокування:

• Інтеграція не кешує довідники закладів та перезавантажує каталоги при кожному новому запиті, що створює необґрунтоване навантаження на API;
• Інтеграція працює під високим навантаженням (створює багато замовлень), але не використовує групові методи, котрі повертають інформацію про велику кількість замовлень одразу. Замість цього вона циклічно переглядає список усіх замовлень і запитує статус кожного з них;
• Інтеграція запитує списки найменувань (номенклатури) одночасно для всіх RMS, котрі входять у мережу HQ, що створює невиправдане навантаження на API. Правильним рішенням являється запит списку найменувань для кожного RMS по черзі;
• Інші випадки.

     Неможливо описати усі варіанти, що призводять до обмеження. Однак випадки некоректного використання API будуть регулярно оновлюватись.