Blokady i ograniczenia Syrve Live API
Otwarte systemy API w chmurze zawsze mają ograniczenia dotyczące ich użytkowania 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 niewłaściwego działania usługi.
Live API ma 2 rodzaje ograniczeń dotyczących pracy z API:
- Całkowite zablokowanie logowania do API;
- 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 działanie jakiejkolwiek części naszego systemu.
Blokada może zostać 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ż później radzić sobie z takimi zamówieniami przy kasie;
- zbyt wiele zamówień;
- jeśli Twoja integracja tworzy ponad 1000 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 da się opisać wszystkich opcji prowadzących do blokady. Będziemy jednak regularnie 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 wysyłać 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 tej grupy będą natychmiast zwracać kod odpowiedzi 429.
Przykłady grup zapytań:
- katalogi (obejmuje wszystkie katalogi pobierane dla sieci);
- szczegóły zamówień (obejmuje cały zestaw metod zwracających zamówienia);
- i inne.
Przykłady sytuacji, kiedy 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 tworzy nieracjonalne obciążenie API;
- integracja działa pod dużym obciążeniem (tworzy wiele zamówień), ale nie korzysta z metod grupowych zwracających informacje o wielu zamówieniach jednocześnie. Zamiast tego przechodzi po liście wszystkich zamówień i żąda statusu dla każdego z nich;
- integracja żąda list stanów magazynowych w jednym momencie dla wszystkich RMS włączonych w łańcuch, co tworzy nieracjonalne obciążenie API. Poprawnym rozwiązaniem byłoby żądanie listy stanów magazynowych dla każdego RMS pojedynczo;
- inne przypadki.
Nie da się opisać wszystkich opcji prowadzących do ograniczenia. Będziemy jednak regularnie aktualizować przypadki niewłaściwego użycia API.