O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
Por que contamos requisições em lote por item, e não por chamada
Um endpoint de lote que aceita mil endereços em uma única chamada e conta apenas como uma requisição na sua cota parece generoso em uma página de preços. Não é generoso. É um erro de arredondamento esperando para virar um problema de capacidade, porque o trabalho real por trás dessa chamada, mil consultas individuais, não diminuiu só porque chegou em um único envelope.
Contamos requisições em massa e em lote da mesma forma que contamos todo o resto: um item, uma requisição. Se você envia mil endereços em uma única chamada em lote, isso equivale a mil requisições na sua cota gratuita ou no seu crédito pré-pago, exatamente como se você tivesse chamado o endpoint mil vezes separadamente. A conveniência do lote, menos idas e voltas, menos sobrecarga de conexão, é real e vale a pena. O custo das consultas em si não muda porque você as pediu juntas.
Cobrar artificialmente menos por chamadas em lote cria uma distorção estranha. Isso recompensa reestruturar sua integração em torno de grandes chamadas em lote apenas para economizar dinheiro, e não porque o processamento em lote realmente se encaixa no seu fluxo de trabalho. Também torna mais difícil entender, de fora, o planejamento de capacidade real de um provedor, já que uma "requisição" deixa de significar uma unidade de trabalho consistente. Um cliente que compara provedores pelo número de requisições por dia não consegue fazer uma comparação justa se a requisição de um provedor pode conter secretamente mil consultas e a de outro não.
A contagem por item também mantém nossos cabeçalhos de cota significativos. Toda resposta traz a contagem do que você já usou e do que resta, e esse número só significa algo se uma requisição for uma requisição, independentemente do formato em que foi enviada. Se um lote de mil itens custasse discretamente uma única unidade, esses cabeçalhos quase não diriam nada sobre o seu consumo real, e você só descobriria o número verdadeiro quando um padrão de uso muito maior e sem lotes atingisse um limite que você não esperava.
Há também um argumento de justiça. Um cliente que envia chamadas individuais e um cliente que envia lotes estão nos pedindo a mesma quantidade total de trabalho pelo mesmo preço total. Cobrar menos por consulta do cliente de lotes, só porque as requisições vêm agrupadas, significaria que o cliente de chamadas individuais está, na prática, subsidiando uma infraestrutura que não é ele quem está sobrecarregando. Cobrar o mesmo por consulta dos dois mantém o preço ligado ao trabalho, e não à forma como o trabalho foi empacotado.
Nada disso torna o processamento em lote inútil. Ele continua sendo a maneira certa de enviar um conjunto grande e conhecido de consultas em uma única ida e volta, e nós o oferecemos porque menos conexões e menos sobrecarga representam um ganho real de eficiência do seu lado. O que o lote não deve fazer, em nenhum dos lados da requisição, é mudar o custo real das consultas. Mil consultas são mil consultas, cheguem elas uma de cada vez ao longo de uma tarde ou todas de uma vez em uma única chamada.