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 construímos isto do jeito que gostaríamos de comprar
Nós construímos e operamos uma API de geocodificação. A empresa é só isso. Cada decisão descrita no restante destes posts (preço por requisição em vez de licenças por usuário, um nível gratuito sem chave em vez de um período de teste com contagem regressiva, hosts de compatibilidade em vez de um formato proprietário, cabeçalhos de cota em toda resposta em vez de um painel atrasado) remonta ao mesmo teste simples que continuamos aplicando enquanto o construíamos: isso nos incomodaria se fôssemos o cliente do outro lado?
A maioria dos maus hábitos sobre os quais escrevemos ao longo desta coleção reprova nesse teste de imediato, assim que você se imagina sendo quem paga por eles. Ninguém quer descobrir um limite de taxa por meio de uma requisição que falhou em produção. Ninguém quer um plano "ilimitado" que acaba tendo uma política de uso justo anexada. Ninguém quer uma migração que leva um trimestre porque o SDK do provedor anterior espalhou seus formatos por uma base de código durante anos. Essas não são queixas obscuras. São coisas que quase todo desenvolvedor já viveu do outro lado de uma relação com uma API, e é exatamente por isso que não achamos que seja preciso pesquisa com clientes para identificá-las como problemas que vale a pena evitar.
Os preços foram o lugar mais claro para aplicar isso. 2.500 requisições gratuitas por dia a partir de qualquer endereço, sem chave nenhuma. Quando você precisar de mais, cadastre-se com um endereço de e-mail e recarregue crédito pré-pago a € 0,0001 por requisição ou adquira uma chave Unlimited por € 50 por mês. Todos os endpoints e todos os hosts compatíveis custam o mesmo. Não chegamos a isso fazendo um exercício de otimização de preços para maximizar a receita por cliente. Chegamos perguntando como seria um preço justo e honesto para este produto específico aos olhos de alguém que já se frustrou com níveis opacos, taxas por excedente e ligações de vendas corporativas, porque todos nós já fomos esse alguém em algum momento.
O mesmo teste vale para decisões menores que nunca aparecem em uma página de preços: aceitar uma chave por cabeçalho, bearer token, Basic auth ou parâmetro de consulta sem custo extra, porque impor um padrão específico é um atrito desnecessário para quem já tem código que faz isso de outro jeito. Publicar códigos de erro e limites de taxa com clareza, porque tentar adivinhar uma falha não documentada é perda de tempo para todo mundo. Nenhuma dessas decisões é dramática. Elas são o acúmulo de não fazer a coisa irritante, repetidamente, em todas as partes do produto.
Não estamos afirmando que isso deixa todas as partes do produto prontas ou perfeitas. Somos específicos sobre quais endpoints consideramos totalmente funcionais e quais, como a geocodificação direta, a geocodificação reversa e o preenchimento automático, descrevemos com cuidado em vez de exagerar, porque exagerar é outra versão da mesma falha: dizer ao cliente o que ele quer ouvir em vez do que é de fato verdade. Construir o produto que gostaríamos de comprar significa construí-lo com honestidade, inclusive sobre os seus limites atuais, e não apenas construir as partes das quais é fácil se orgulhar. Esse é o critério que definimos para nós mesmos, e é por ele que pretendemos continuar sendo avaliados.