Como usar esta lista de APIs públicas

Escolha uma API e uma habilidade. Escreva três casos: o caminho feliz, um caso de borda e um caso em que você espera uma falha e verifica se ela tem o formato correto. O terceiro é justamente o que a maioria das pessoas pula e o que separa uma suíte que encontra bugs de uma suíte que apenas confirma que o serviço está no ar.

Um aviso antes de começar. São serviços compartilhados, mantidos por voluntários ou oferecidos por empresas como cortesia. Mantenha o volume baixo, não aponte um gerador de carga para eles e armazene as respostas em cache sempre que puder.

Para aprender o básico de requisição e resposta

  • JSONPlaceholder. Uma API REST falsa com posts, comentários, usuários e tarefas. Aceita escritas e finge persisti-las. Pratique: verbos CRUD, códigos de status e a diferença entre uma requisição que teve sucesso e uma alteração que realmente persistiu. O fato de as escritas não serem salvas de verdade transforma isso numa lição especialmente boa sobre verificar resultados em vez de respostas.

  • HTTPBin. Um endpoint que devolve tudo o que você envia, além de rotas que retornam qualquer código de status que você pedir, atrasam de propósito ou devolvem payloads malformados. Pratique: timeouts, retentativas, tratamento de redirecionamentos e comportamento de cabeçalhos. Se você quiser ver como a sua suíte reage a um 503, dá para produzir um sob demanda.

  • REST Countries. Dados de países com um formato estável, bem documentado e sem exigir chave. Pratique: asserções de schema e validação campo a campo em um payload grande o bastante para ser interessante e pequeno o bastante para ser lido.

Para paginação e coleções grandes

PokéAPI

  • Um conjunto de dados grande e cheio de referências cruzadas, com paginação padrão por offset e limit.

  • Pratique: percorrer páginas, verificar se uma varredura completa retorna a contagem que a coleção declara e pegar erros de off-by-one nos limites de página.

Open Library

  • Registros de livros e autores com busca, e muitos registros com campos ausentes ou inconsistentes.

  • Pratique: tolerar campos opcionais. Dados reais são bagunçados, e uma suíte que presume que todo registro está completo quebra no primeiro contato com a produção.

GitHub REST API

  • Funciona sem autenticação em volume baixo e autenticada com um token.

  • Pratique: paginação por link header, requisições condicionais e a diferença de comportamento antes e depois de você se autenticar.

Para autenticação e limites de requisições

GitHub, autenticado

  • Pratique: manipulação de tokens, erros de escopo e verificar se uma requisição sem permissão falha do jeito certo, em vez de falhar de forma genérica.

Open-Meteo

  • Previsões do tempo, sem chave, com uma política de uso justo publicada.

  • Pratique: combinações de parâmetros de consulta e dados baseados em tempo, em que a resposta correta muda a cada execução. Bom treino para asserções que não podem ser comparações exatas.

HTTPBin de novo

  • Pratique: fluxos de basic auth e bearer token contra endpoints feitos justamente para exercitá-los, sem arriscar a cota de outra pessoa.

Três asserções que vale a pena praticar em qualquer API pública

Seja qual for o serviço escolhido, estes são os hábitos que você leva para a sua própria API.

  • Verifique o corpo, não apenas o status. Um 200 trazendo uma lista vazia onde deveria haver um registro é um bug que uma asserção de código de status vai alegremente dar como aprovado. Só esse hábito encontra mais defeitos reais do que qualquer outro.

  • Verifique se as falhas falham corretamente. Peça algo que não existe e confira se você recebe o código certo e um formato de erro utilizável. Serviços que retornam 200 com um objeto de erro dentro são comuns, e uma suíte que não sabe disso vai reportar verde para sempre.

  • Verifique relacionamentos, não apenas campos. Se um post referencia um usuário, busque esse usuário e confira se ele existe. Os bugs mais interessantes vivem entre dois endpoints, não dentro de um.

Apontando um agente para uma delas

Se você quer ver como é uma cobertura gerada antes de experimentar no seu próprio serviço, uma API pública é um lugar seguro para isso. Não há dados para poluir nem ambiente para quebrar.

Aponte um projeto para a URL base e deixe a descoberta enumerar os endpoints; depois leia o plano gerado antes de executar qualquer coisa. O plano é a parte interessante. Vale prestar atenção em duas coisas no caminho.

  • Ele captura valores em vez de fixá-los no código? Uma chamada de criação retorna um identificador, e a chamada seguinte deveria usá-lo. Identificadores fixos no código são o motivo mais comum de uma suíte funcionar uma única vez.

  • Ele ordena corretamente as chamadas dependentes? Você não consegue buscar um comentário em um post que nunca foi criado. Observe se o plano entende isso ou apenas lista os endpoints em ordem alfabética.

Depois execute e leia as falhas. Em uma API pública, a maioria das falhas será das suas suposições, e não do serviço, o que é exatamente a lição.

Se você prefere ser dono do código de teste, a CLI segue um caminho diferente para o trabalho de backend: você mesmo escreve as chamadas e as asserções em Python, declara o que cada teste precisa e o que produz, e marca a limpeza como um teste separado. Isso dá mais trabalho no começo e coloca a suíte no seu repositório, o que alguns times querem e outros não.

Do treino para o seu próprio serviço

A distância entre praticar em uma API pública e testar a sua é maior do que parece, e saber onde a dificuldade dá um salto poupa alguma frustração.

APIs públicas são sem estado do seu ponto de vista: você lê e, o que quer que escreva, não persiste ou não importa. O seu próprio serviço é o oposto. No momento em que você testa algo real, você herda autenticação que expira, registros que precisam existir antes de outros registros, valores que só existem em tempo de execução e a obrigação de limpar a bagunça depois.

Nada disso aparece em um tutorial e tudo isso aparece na primeira semana. Então trate a fase das APIs públicas como o aprendizado de asserções, que se transfere por completo, e espere que o tratamento de estado seja uma coisa à parte, que você aprende depois, e não a continuação da mesma habilidade.

O que não fazer com elas

  • Não as use para teste de carga. Elas são gratuitas, compartilhadas, e alguém paga a conta.

  • Não crie uma dependência de produção em cima de nenhuma delas. Os termos mudam, projetos são arquivados e voluntários se cansam.

  • Não trate uma suíte que passa contra o JSONPlaceholder como prova de que a sua API está correta. Isso mostra que a sua configuração de testes funciona, o que é genuinamente útil, mas é uma afirmação bem menor.

Experimentando isso em um serviço real

Quando os hábitos de asserção já estiverem confortáveis, o salto para a sua própria API é onde começam os problemas de estado, e essa é a parte que o TestSprite resolve como produto. Auto-Authentication mantém as sessões vivas durante toda a execução. Dynamic Variables levam um identificador de uma chamada de criação até a chamada de exclusão. Dependency Chains descobrem o que precisa acontecer primeiro. Auto-Cleanup remove o que a execução criou.

Começar no seu próprio serviço se parece com o exercício de API pública acima: aponte um projeto para a URL base, deixe a descoberta enumerar os endpoints e leia o plano gerado antes de qualquer execução. A diferença é que agora o plano cobre casos de autorização e de borda, e a execução não deixa nada para trás.

É seguro experimentar primeiro em uma API pública, já que não há dados para poluir, e o plano diz mais sobre a ferramenta do que os resultados vão dizer.

Por qual devo começar?

JSONPlaceholder na primeira hora, porque nada pode dar errado. Depois HTTPBin, porque ele deixa você provocar falhas de propósito, e é praticando contra falhas que o aprendizado acontece.

Alguma dessas precisa de chave de API?

A maioria desta lista funciona sem chave. O GitHub funciona sem autenticação em volume baixo, e vale a pena pegar um token justamente porque isso permite praticar fluxos autenticados.

Posso usar essas APIs em um pipeline de CI?

Para uma pequena suíte de tutorial, sim. Para qualquer coisa que rode a cada commit, execute contra um mock local. Apontar a CI para um serviço mantido por voluntários é exatamente assim que um recurso gratuito útil deixa de ser gratuito.

Qual a diferença entre isso e uma coleção do Postman com APIs públicas?

Uma coleção entrega requisições. Esta lista é organizada em torno do que cada serviço ensina, o que importa mais quando o objetivo é ficar melhor em testes, e não fazer uma chamada dar certo.

Qual é a forma mais rápida de ver uma cobertura gerada?

Aponte um projeto para uma URL base pública, deixe a descoberta enumerar os endpoints e leia o plano antes de executar qualquer coisa. O plano diz mais sobre a ferramenta do que os resultados.

Resumindo

Escolha uma API, pratique uma habilidade e sempre escreva o caso que falha.

APIs públicas são o lugar mais seguro para aprender como é uma boa cobertura, porque não há nada para quebrar. Quando chegar a hora, aponte a mesma abordagem para o seu próprio serviço e mantenha o hábito de verificar corpos, falhas e relacionamentos.

Comece gratuitamente Fale com a gente