/v1 aplica dois orçamentos de solicitações independentes. Uma solicitação
é recusada se qualquer um dos orçamentos estiver esgotado.
O orçamento por chave acompanha a chave onde quer que ela seja utilizada. O orçamento por IP
é o único orçamento para o tráfego não autenticado e um segundo limite para
o tráfego autenticado.
Os limites são aplicados antes da autenticação; portanto, as solicitações com credenciais inválidas ou
ausentes também são contabilizadas no orçamento da origem. Os orçamentos numéricos exatos são
configurados pelo operador e podem mudar; o contrato de resposta descrito abaixo
é a interface estável sobre a qual você deve desenvolver.
apikey:secret ou secret:).
Defina BASE como o host regional da organização — consulte
Regiões.
A resposta 429
Quando um orçamento é esgotado, a API retorna429 Too Many Requests com um
cabeçalho Retry-After (em segundos) e o corpo padrão de detalhes do problema:
429 Too Many Requests
429 da
mesma forma: aguarde e, em seguida, tente novamente.
Tratamento de respostas 429
1
Respeite o Retry-After
Aguarde pelo menos o número de segundos indicado no cabeçalho
Retry-After antes de
tentar novamente. Repetir a solicitação antes disso apenas consome novamente o orçamento com solicitações
que serão recusadas.2
Aplique recuo exponencial em caso de repetição
Se uma nova tentativa for recusada novamente, aumente o intervalo de recuo e adicione um jitter aleatório
para que os processos paralelos não repitam as solicitações de forma sincronizada. Nunca reduza o
Retry-After do servidor para se ajustar a um limite
local. Se o servidor solicitar uma espera maior do que o seu orçamento de novas tentativas permite,
interrompa o processo e agende o trabalho para mais tarde.3
Suavize a taxa de solicitações
Prefira uma taxa de solicitações constante a picos de tráfego. Para leituras em massa, use o tamanho máximo
de página (
limit=500) para percorrer a coleção com menos solicitações — consulte
paginação. Quando várias listagens forem percorridas em
paralelo (por exemplo, tabelas do Power BI), mantenha a simultaneidade moderada e respeite
Retry-After para que um 429 temporário não faça toda a atualização falhar.429 para uma solicitação GET, com no máximo
cinco tentativas e no máximo 60 segundos de espera entre elas. Ele é interrompido
imediatamente em caso de outros erros. Os tempos limite de rede são propagados ao chamador. Configure
os tempos limite e os orçamentos de novas tentativas de acordo com a sua carga de trabalho. requests interpreta o tempo limite
de leitura como o tempo máximo de inatividade durante o recebimento de dados, e não como um prazo total.
Carregue LIVING_SECURITY_API_KEY a partir do seu gerenciador de segredos. Instale requests
antes de executar este exemplo. Chame get_with_retry("/organization") para utilizá-lo.
Python
Cronograma de atualização recomendado
Dimensione a frequência de atualização de acordo com o orçamento da sua chave e o tamanho da página. Uma carga histórica completa de uma coleção grande representa um custo único; prefira janelas incrementais para as atualizações regulares, de modo que cada execução permaneça bem abaixo do orçamento. Defina semprelimit=500 explicitamente — o padrão de 25 multiplica o número de solicitações.
