/v1 API hanteert twee onafhankelijke aanvraagbudgetten. Een aanvraag wordt
geweigerd als een van beide budgetten is uitgeput.
Het budget per sleutel volgt de sleutel overal waar deze wordt gebruikt. Het
budget per IP is het enige budget voor niet-geauthenticeerd verkeer en een
tweede limiet voor geauthenticeerd verkeer.
Limieten worden afgedwongen vóór de authenticatie, waardoor aanvragen met
ongeldige of ontbrekende inloggegevens ook meetellen voor het budget van de
bron. De exacte numerieke budgetten worden door de operator geconfigureerd en
kunnen wijzigen; het onderstaande responscontract is de stabiele interface
waarop u kunt bouwen.
apikey:secret of secret:).
Stel BASE in op de regionale host van de organisatie; zie
Regio’s.
De 429-respons
Wanneer een budget is uitgeput, retourneert de API429 Too Many Requests met een
Retry-After-header (in seconden) en de standaard problem-details-body:
429 Too Many Requests
429
op dezelfde manier: wacht en probeer het daarna opnieuw.
429-responses afhandelen
1
Houd rekening met Retry-After
Wacht minimaal het aantal seconden dat in de
Retry-After-header staat voordat u
het opnieuw probeert. Als u eerder opnieuw probeert, verbruikt u alleen
opnieuw budget voor aanvragen die toch worden geweigerd.2
Verleng de wachttijd exponentieel bij herhaling
Als een nieuwe poging opnieuw wordt geweigerd, verhoogt u uw backoff en voegt
u willekeurige jitter toe, zodat parallelle workers niet synchroon opnieuw
proberen. Verkort nooit de
Retry-After van de server om binnen een lokale limiet te
passen. Als de server u vraagt langer te wachten dan uw retrybudget toestaat,
stopt u en plant u het werk voor later.3
Spreid uw aanvraagfrequentie
Geef de voorkeur aan een constante aanvraagfrequentie boven pieken. Gebruik
voor bulkleesacties de maximale paginagrootte (
limit=500) om de collectie met
minder aanvragen te doorlopen; zie paginering.
Wanneer meerdere lijstdoorlopen parallel worden uitgevoerd (bijvoorbeeld
Power BI-tabellen), houd de gelijktijdigheid dan bescheiden en houd rekening
met Retry-After, zodat een tijdelijke 429 niet de hele verversing laat mislukken.429-responses opnieuw voor een GET-aanvraag,
met maximaal vijf pogingen en maximaal 60 seconden wachttijd tussen de
pogingen. Bij andere fouten stopt het direct. Netwerktimeouts worden doorgegeven
aan de aanroeper. Configureer timeouts en retrybudgetten naar uw workload.
requests interpreteert de leestimeout als de maximale inactieve tijd tijdens het
ontvangen van gegevens, niet als een algemene deadline.
Laad LIVING_SECURITY_API_KEY uit uw secretmanager. Installeer requests
voordat u dit voorbeeld uitvoert. Roep get_with_retry("/organization") aan om het te gebruiken.
Python
Aanbevolen verversingsschema
Stem de verversingsfrequentie af op uw sleutelbudget en paginagrootte. Een volledige historische load van een grote collectie is een eenmalige kostenpost; geef voor reguliere verversingen de voorkeur aan incrementele vensters, zodat elke run ruim binnen het budget blijft. Stellimit=500 altijd expliciet in; de
standaardwaarde van 25 vermenigvuldigt het aantal aanvragen.
