/v1 aplica dos pressupostos de sol·licituds independents. Una sol·licitud
es rebutja si qualsevol dels dos pressupostos s’ha esgotat.
El pressupost per clau segueix la clau allà on s’utilitzi. El pressupost per IP és
l’únic pressupost per al trànsit no autenticat i un segon límit per al trànsit
autenticat.
Els límits s’apliquen abans de l’autenticació; per tant, les sol·licituds amb
credencials no vàlides o absents també compten contra el pressupost d’origen. Els
pressupostos numèrics exactes els configura l’operador i poden canviar; el
contracte de resposta que es descriu a continuació és la interfície estable sobre
la qual podeu desenvolupar.
apikey:secret o secret:).
Configureu BASE amb l’amfitrió regional de l’organització; consulteu
Regions.
La resposta 429
Quan un pressupost s’esgota, l’API retorna429 Too Many Requests amb una capçalera
Retry-After (en segons) i el cos estàndard de detalls del problema:
429 Too Many Requests
429 de la
mateixa manera: espereu i torneu-ho a intentar.
Gestió dels 429
1
Respecteu Retry-After
Espereu, com a mínim, el nombre de segons indicat a la capçalera
Retry-After abans de
tornar-ho a intentar. Reintentar-ho abans només torna a consumir pressupost en
sol·licituds que es rebutjaran.2
Apliqueu un retard exponencial en cas de repeticions
Si un reintent es rebutja de nou, augmenteu el retard i afegiu-hi un jitter
aleatori perquè els processos paral·lels no reintentin de manera sincronitzada.
No escurceu mai el
Retry-After del servidor per ajustar-lo a un límit local. Si el
servidor us demana que espereu més del que permet el vostre pressupost de
reintents, atureu-vos i programeu la feina per a més tard.3
Suavitzeu la vostra taxa de sol·licituds
És preferible una taxa de sol·licituds constant a les ràfegues. Per a lectures
massives, utilitzeu la mida de pàgina màxima (
limit=500) per cobrir la col·lecció amb
menys sol·licituds; consulteu pagination. Quan
diversos recorreguts de llistes s’executen en paral·lel (per exemple, taules de
Power BI), mantingueu una concurrència moderada i respecteu Retry-After perquè un 429
temporal no faci fallar tota l’actualització.429 en una sol·licitud GET, amb
un màxim de cinc intents i un màxim de 60 segons d’espera entre intents. S’atura
immediatament davant d’altres errors. Els temps d’espera de xarxa es propaguen a
qui fa la crida. Configureu els temps d’espera i els pressupostos de reintents
segons la vostra càrrega de treball. requests interpreta el temps d’espera de lectura
com el temps màxim d’inactivitat durant la recepció de dades, no com un termini
global.
Carregueu LIVING_SECURITY_API_KEY des del vostre gestor de secrets. Instal·leu requests
abans d’executar aquest exemple. Crideu get_with_retry("/organization") per utilitzar-lo.
Python
Calendari d’actualització recomanat
Dimensioneu la cadència d’actualització segons el pressupost de la vostra clau i la mida de pàgina. Una càrrega històrica completa d’una col·lecció gran és un cost únic; per a les actualitzacions en règim estacionari, són preferibles les finestres incrementals, de manera que cada execució quedi ben per sota del pressupost. Configureu semprelimit=500 de manera explícita: el valor per defecte de 25 multiplica
el nombre de sol·licituds.
