/v1 egzekwuje dwa niezależne budżety żądań. Żądanie jest odrzucane,
jeśli którykolwiek z budżetów został wyczerpany.
Budżet przypisany do klucza obowiązuje wszędzie tam, gdzie klucz jest używany. Budżet
przypisany do adresu IP jest jedynym budżetem dla ruchu nieuwierzytelnionego oraz drugim
limitem dla ruchu uwierzytelnionego.
Limity są egzekwowane przed uwierzytelnieniem, więc żądania z nieprawidłowymi lub
brakującymi danymi uwierzytelniającymi również wliczają się do budżetu źródła. Dokładne wartości liczbowe
budżetów są konfigurowane przez operatora i mogą ulec zmianie; przedstawiony poniżej kontrakt odpowiedzi
jest stabilnym interfejsem, na którym należy oprzeć implementację.
apikey:secret lub secret:).
Ustaw BASE na regionalny host organizacji — zobacz
Regiony.
Odpowiedź 429
Gdy budżet zostanie wyczerpany, interfejs API zwraca429 Too Many Requests wraz z nagłówkiem
Retry-After (w sekundach) oraz standardową treścią problem-details:
429 Too Many Requests
429 należy traktować
tak samo: poczekać, a następnie ponowić żądanie.
Obsługa odpowiedzi 429
1
Przestrzegaj nagłówka Retry-After
Przed ponowieniem żądania odczekaj co najmniej liczbę sekund podaną w nagłówku
Retry-After.
Wcześniejsze ponowienie jedynie zużywa budżet na żądania, które i tak
zostaną odrzucone.2
Stosuj wykładniczy backoff przy kolejnych odmowach
Jeśli ponowione żądanie zostanie ponownie odrzucone, wydłuż czas oczekiwania i dodaj losowy jitter,
aby równoległe procesy robocze nie ponawiały żądań w tym samym momencie. Nigdy nie skracaj wartości
Retry-After serwera w celu dopasowania do lokalnego
limitu. Jeśli serwer wymaga dłuższego oczekiwania, niż pozwala na to Twój budżet ponowień,
zatrzymaj się i zaplanuj wykonanie zadania na później.3
Wygładź tempo wysyłania żądań
Preferuj stałe tempo żądań zamiast gwałtownych serii. Przy zbiorczym odczycie danych użyj maksymalnego
rozmiaru strony (
limit=500), aby objąć kolekcję mniejszą liczbą żądań — zobacz
paginację. Gdy równolegle przebiega kilka przejść po listach
(na przykład tabele Power BI), utrzymuj umiarkowaną współbieżność i przestrzegaj
Retry-After, aby tymczasowa odpowiedź 429 nie powodowała niepowodzenia całego odświeżania.429 dla żądania GET, maksymalnie
pięć prób i z czasem oczekiwania między próbami nie dłuższym niż 60 sekund. W przypadku innych błędów
natychmiast się zatrzymuje. Przekroczenia czasu sieciowego są przekazywane do wywołującego. Skonfiguruj
limity czasu i budżety ponowień odpowiednio do swojego obciążenia. requests interpretuje limit czasu odczytu
jako maksymalny czas bezczynności podczas odbierania danych, a nie jako całkowity termin.
Wczytaj LIVING_SECURITY_API_KEY z menedżera sekretów. Zainstaluj requests
przed uruchomieniem tego przykładu. Wywołaj get_with_retry("/organization"), aby go użyć.
Python
Zalecany harmonogram odświeżania
Dobierz częstotliwość odświeżania do budżetu klucza i rozmiaru strony. Pełne załadowanie danych historycznych dużej kolekcji to koszt jednorazowy; w odświeżaniach w stanie ustalonym preferuj okna przyrostowe, aby każde uruchomienie mieściło się znacznie poniżej budżetu. Zawsze ustawiajlimit=500 jawnie — wartość domyślna 25 zwielokrotnia liczbę żądań.
