/v1 aplica dos presupuestos de solicitudes independientes. Una solicitud
se rechaza si cualquiera de los dos presupuestos se ha agotado.
El presupuesto por clave acompaña a la clave dondequiera que se utilice. El presupuesto por IP
es el único presupuesto para el tráfico no autenticado y un segundo límite para
el tráfico autenticado.
Los límites se aplican antes de la autenticación, por lo que las solicitudes con credenciales no válidas o
ausentes también cuentan para el presupuesto del origen. Los presupuestos numéricos exactos los configura el operador y pueden cambiar; el contrato de respuesta que se describe a continuación
es la interfaz estable sobre la que debe desarrollar.
apikey:secret o secret:).
Establezca BASE con el host regional de la organización; consulte
Regiones.
La respuesta 429
Cuando se agota un presupuesto, la API devuelve429 Too Many Requests con un
encabezado Retry-After (en segundos) y el cuerpo estándar de detalles del problema:
429 Too Many Requests
429 de la
misma manera: espere y vuelva a intentarlo.
Gestión de las respuestas 429
1
Respete Retry-After
Espere como mínimo el número de segundos indicado en el encabezado
Retry-After antes de
reintentar. Reintentar antes solo vuelve a consumir presupuesto en solicitudes que serán
rechazadas.2
Aplique un retroceso exponencial en los reintentos repetidos
Si un reintento vuelve a ser rechazado, aumente el tiempo de retroceso y añada una variación aleatoria (jitter)
para que los procesos paralelos no reintenten al mismo tiempo. Nunca reduzca el valor de
Retry-After del servidor para ajustarlo a un
límite local. Si el servidor le pide esperar más de lo que permite su presupuesto de reintentos,
deténgase y programe la tarea para más tarde.3
Suavice su tasa de solicitudes
Es preferible una tasa de solicitudes constante a las ráfagas. Para lecturas masivas, utilice el tamaño de página
máximo (
limit=500) para cubrir la colección con menos solicitudes; consulte
paginación. Cuando se ejecuten varios recorridos de listas en
paralelo (por ejemplo, tablas de Power BI), mantenga una concurrencia moderada y respete
Retry-After para que un 429 temporal no haga fallar toda la actualización.429 en una solicitud GET, con un máximo de
cinco intentos y un máximo de 60 segundos de espera entre intentos. Se detiene
de inmediato ante otros errores. Los tiempos de espera agotados de red se propagan al llamador. Configure
los tiempos de espera y los presupuestos de reintentos según su carga de trabajo. requests interpreta el tiempo de espera de lectura
como el tiempo máximo de inactividad durante la recepción de datos, no como un plazo global.
Cargue LIVING_SECURITY_API_KEY desde su gestor de secretos. Instale requests
antes de ejecutar este ejemplo. Llame a get_with_retry("/organization") para utilizarlo.
Python
Programación de actualización recomendada
Dimensione la frecuencia de actualización en función del presupuesto de su clave y del tamaño de página. Una carga histórica completa de una colección grande supone un coste único; para las actualizaciones en régimen estable, prefiera ventanas incrementales, de modo que cada ejecución se mantenga muy por debajo del presupuesto. Establezca siemprelimit=500 de forma explícita: el valor predeterminado de 25 multiplica el número de solicitudes.
