Syrve Live API Blokady i Ograniczenia

Otwarte systemy API w chmurze zawsze mają ograniczenia w użytkowaniu ze względu na potrzebę zapewnienia jak największej niezawodności i stabilności usługi dla klientów.

Aby zapewnić działanie usługi o dużym obciążeniu, powinniśmy analizować ruch i ograniczać przypadki nieprawidłowego działania usługi.

Live API ma 2 rodzaje ograniczeń dotyczących pracy z API:

1. Całkowite zablokowanie logowania do API;
2. Ograniczenie logowania do API ze względu na liczbę zapytań.

Blokowanie logowania do API

Ten rodzaj ograniczenia dotyczy logowań do API tylko wtedy, gdy integracja znacząco zakłócałaby działanie jakiejkolwiek części naszego systemu.

Blokada może być zastosowana w następujących przypadkach:

• masowe wysyłanie tych samych zapytań;
  • zazwyczaj wynika to z faktu, że integracja nie weryfikuje odpowiedzi z naszej usługi;
• wysoki odsetek błędnych zapytań;
  • błędy integracji nie są naprawiane. Dotyczy to szczególnie wysyłania zapytań do tworzenia zamówienia. W takim przypadku łatwiej jest wyłączyć taką integrację niż zajmować się takimi zamówieniami przy kasie później;
• zbyt wiele zamówień;
  • jeśli Twoja integracja tworzy ponad 1 000 zamówień dziennie dla jednego sklepu, najprawdopodobniej korzystasz z naszego systemu nieprawidłowo;
• szczytowe obciążenie dla dowolnych grup metod API;
  • zazwyczaj wynika to z błędów w logice integracji;
• testy obciążeniowe i/lub testy wytrzymałościowe przez integrację;
  • testy obciążeniowe w środowisku produkcyjnym są zabronione dla jakichkolwiek integracji, więc gdy nasz system wykryje takie integracje, może je trwale zablokować;
• inne przypadki
  • Nie jest możliwe opisanie wszystkich opcji prowadzących do blokady. Jednak regularnie będziemy aktualizować przypadki niewłaściwego użycia API.

Ograniczenie logowania do API ze względu na liczbę zapytań lub „Zbyt wiele zapytań” (kod odpowiedzi 429)

To ograniczenie dotyczy logowania do API tylko wtedy, gdy integracja zaczyna wykonywać nieracjonalnie dużą liczbę zapytań do tej samej grupy zapytań.

Jak to działa:

• wszystkie metody API są podzielone na grupy zapytań na podstawie zwracanych danych;
• każda metoda należy do jednej grupy zapytań;
• maksymalna dopuszczalna liczba zapytań w jednym przedziale czasowym dla każdej grupy zapytań jest ustalana przez eksperta na podstawie analizy danych historycznych. Jednocześnie liczba takich zapytań:
  • nie zależy od liczby sklepów, z którymi integracja współpracuje: dla metod do pracy z katalogami sieciowymi;
  • zależy od liczby sklepów, z którymi integracja współpracuje: dla metod do pracy z zamówieniami, listą stanów magazynowych i innymi danymi zależnymi od sklepu.
• przedział czasowy różni się dla różnych grup metod (zazwyczaj od 1 do 10 minut)
  • w większości przypadków wynosi 1 minutę.
• jeśli integracja osiągnęła już maksymalną dozwoloną liczbę zapytań do konkretnej grupy zapytań w bieżącym przedziale czasowym, to do czasu zakończenia tego przedziału wszystkie zapytania do metod z tej grupy będą natychmiast zwracać kod odpowiedzi 429.

Przykłady grup zapytań:

• katalogi (obejmuje wszystkie katalogi pobierane dla sieci);
• szczegóły zamówienia (obejmuje cały zestaw metod zwracających zamówienia);
• i inne.

Przykłady sytuacji, w których może zostać zastosowana blokada:

• integracja nie buforuje katalogów sklepów po stronie integracji i ponownie ładuje katalogi przy każdym nowym zapytaniu, co powoduje nieracjonalne obciążenie API;
• integracja działa pod dużym obciążeniem (tworzy wiele zamówień), ale nie korzysta z metod grupowych, które zwracają informacje o wielu zamówieniach naraz. Zamiast tego przechodzi przez listę wszystkich zamówień i pobiera status dla każdego z nich;
• integracja pobiera listy stanów magazynowych w jednym momencie dla wszystkich RMS wchodzących w skład sieci, co powoduje nieracjonalne obciążenie API. Poprawnym rozwiązaniem byłoby pobieranie listy stanów magazynowych dla każdego RMS pojedynczo;
• inne przypadki.

Nie jest możliwe opisanie wszystkich opcji prowadzących do ograniczenia. Jednak regularnie będziemy aktualizować przypadki niewłaściwego użycia API.