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.
O que o setor ainda erra na adoção do IPv6
O IPv6 está disponível há tempo suficiente para que tratá-lo como uma preocupação secundária não seja mais um atalho de engenharia razoável, e mesmo assim muitas ferramentas relacionadas a IP ainda se comportam como se o IPv4 fosse o tráfego de verdade e o IPv6 fosse a exceção a ser tratada se sobrar tempo. Isso aparece de formas pequenas: lógica de limite de taxa escrita em torno de blocos de endereços no estilo IPv4 sem um conceito equivalente e bem pensado para IPv6, ou documentação que pressupõe discretamente um formato de endereço IPv4 nos exemplos e deixa o tratamento do IPv6 como uma reflexão tardia implícita.
Construímos o controle de cota por rede em torno das duas famílias de endereços de propósito, e não como um remendo de IPv6 acoplado a uma lógica pensada primeiro para IPv4. Cada rede recebe uma cota gratuita compartilhada, um bloco /24 para endereços IPv4 e um bloco /48 para endereços IPv6, e ambos são tratados como agrupamentos de primeira classe, em vez de um ser o projeto principal e o outro uma adaptação. A distinção entre um /24 e um /48 não é arbitrária. Ela reflete como cada família de endereços é realmente alocada pelos registros regionais de internet responsáveis por distribuir os blocos, então o agrupamento significa a mesma coisa na prática, uma rede de tamanho razoável, nos dois casos.
Errar nisso importa especialmente para uma API de dados de localização e de IP, porque toda a categoria de consultas por rede e baseadas em IP depende de interpretar, comparar e aplicar limites de taxa corretamente nos dois formatos de endereço. Uma API que trata discretamente o IPv6 como um caso atípico tem mais chance de produzir um comportamento de cota inconsistente, agrupamentos de rede incorretos ou falhas de interpretação puras e simples para o tráfego IPv6, justamente no momento em que a adoção do IPv6 continua crescendo e uma parcela significativa das requisições reais chega por ele, e não por IPv4.
Parte do motivo pelo qual o setor como um todo investe pouco nisso é que o tráfego IPv4 ainda representa uma grande parcela do volume total de muitos serviços, o que faz os casos atípicos de IPv6 parecerem de baixa prioridade em relação ao esforço de acertá-los de verdade. Achamos que esse raciocínio desconta demais a tendência. Uma parcela do tráfego que não para de crescer não é bem atendida por uma infraestrutura que a trata como um caso permanentemente minoritário, e o custo de corrigir o tratamento de IPv6 direito só aumenta quanto mais tempo a lógica central de um sistema é construída supondo o IPv4 como padrão.
Nada disso é uma afirmação dramática. É um pedido para levar o IPv6 tão a sério quanto o IPv4 no projeto real da limitação de taxa, do controle de cota e da lógica de consulta, e não apenas em uma caixa de conformidade que diz que uma API tecnicamente aceita endereços IPv6 sem erro de sintaxe. Aceitar um formato de endereço e tratá-lo com o mesmo cuidado que o mais comum são conquistas diferentes, e boa parte da infraestrutura deste setor só conseguiu de fato a primeira.