Melhores ferramentas CLI leves para teste de API

A maioria das ferramentas de teste de API exige que você abra uma janela, faça login e clique em um workspace antes de enviar uma única requisição. Isso é bom para uma primeira olhada. Mas é o formato errado para o terminal, onde você quer digitar uma linha, ler a resposta e seguir em frente. Ferramentas de linha de comando leves invertem a ordem: a ferramenta sai do caminho e a requisição é toda a interação.

Leve aqui significa algo específico. Uma instalação pequena, frequentemente um único binário ou um `npx` rápido. Inicialização veloz, para que acessar um endpoint pareça instantâneo. Pouca ou nenhuma configuração para executar a primeira requisição. Saída priorizando o terminal que você pode direcionar para `jq` ou grep. Esta é uma questão diferente de "qual ferramenta é de código aberto" ou "qual tem mais recursos". É sobre pegada e atrito. Para uma pesquisa mais ampla que também abrange GUIs hospedadas, consulte o resumo das melhores ferramentas gratuitas de teste de API.

Abaixo estão oito ferramentas CLI leves para testar APIs REST e HTTP, ordenadas aproximadamente das menores e mais manuais para as que executam suítes de teste completas em CI. Cada entrada possui um comando de instalação real, um comando que mostra seu funcionamento, para que é melhor e uma limitação honesta. A última, a CLI do Apidog, é o binário leve que executa os cenários que você constrói visualmente e controla um pipeline com seu código de saída.

O que torna uma ferramenta CLI "leve" para teste de API

Muitas ferramentas rodam em um terminal. Nem todas parecem leves. Para esta lista, uma ferramenta se qualifica em quatro pontos:

• Pequena pegada. Um único binário, uma instalação `pip`/`npm` ou um comando `npx` de uma linha. Nenhum ambiente de execução que você precise configurar primeiro, idealmente nenhum daemon.
• Inicialização rápida. A ferramenta inicia e envia a requisição sem aquecimento. Binários Rust e Go se destacam aqui; qualquer coisa que inicialize um ambiente de execução pesado perde.
• Configuração baixa ou zero. Você pode enviar a primeira requisição sem arquivo de projeto, sem conta, sem login. A configuração é opcional, para quando você quiser salvar e repetir.
• Saída nativa do terminal. Os resultados são impressos em um formato que você pode ler rapidamente e direcionar para outro comando. Códigos de saída significam algo, então o CI pode usá-los como um controle.

As ferramentas se destacam nos três primeiros pontos; as duas últimas se apoiam no quarto, porque é aí que um binário leve ganha seu lugar em um pipeline. Se você quer o lado interativo, de "acessar um endpoint manualmente", em mais profundidade, o guia alternativas ao curl para teste de API REST aborda os clientes manuais com mais detalhes.

curl: a linha de base que já está instalada

Curl é a ferramenta que você quase certamente já possui. Ela vem com macOS, a maioria das distribuições Linux e Windows modernos, então a instalação mais leve é não instalar nada. Ela suporta HTTP, HTTPS e uma longa lista de outros protocolos, e é a referência contra a qual todos os outros clientes se comparam.

# Already on your machine; check the version
curl --version

# POST JSON and print only the HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

Melhor para: requisições rápidas e avulsas, scripts e qualquer ambiente onde você não pode instalar nada novo. Limitação honesta: a ergonomia é antiquada. Você define os cabeçalhos manualmente, o JSON não é formatado de forma elegante e a asserção em uma resposta significa direcionar para `jq` e verificar um código de saída por conta própria. Ele envia e mostra; não testa.

HTTPie: curl para humanos

HTTPie faz as mesmas requisições que o curl, com uma sintaxe construída para pessoas. O comando é `http`, cabeçalhos e campos JSON são pares simples `chave=valor`, e a saída é colorida e formatada por padrão. É escrito em Python, então precisa de um ambiente de execução Python, o que o torna mais pesado do que um único binário, mas ainda assim uma instalação de uma linha.

python -m pip install httpie   # or: brew install httpie

# POST JSON: age:=24 sends a number, name= sends a string
http POST httpbin.org/post name=acme age:=24 plan=pro

Melhor para: explorar uma API manualmente quando você quer uma saída legível sem muitas flags. Limitação honesta: a inicialização do Python é visivelmente mais lenta do que a de um binário compilado, e a instalação em um sistema limpo significa puxar o Python se ele não estiver presente. Como o curl, é um cliente, não um executor de testes; você lê a resposta, não faz asserções sobre ela.

xh: a velocidade do HTTPie em um único binário

xh reimplementa a sintaxe amigável do HTTPie em Rust e é entregue como um único binário estaticamente linkado. Você obtém a mesma ergonomia de `chave=valor` e saída colorida, com inicialização mais rápida e nada para instalar além do próprio binário. Ele suporta HTTP/2 e pode até imprimir o comando curl equivalente com `--curl`.

brew install xh   # or: cargo install xh --locked

# Same syntax as HTTPie, faster start
xh POST httpbin.org/post name=acme age:=24 plan=pro

Melhor para: desenvolvedores que gostam da sensação do HTTPie, mas querem um único binário rápido e sem tempo de execução. Limitação honesta: ele não implementa todos os recursos do HTTPie e não há um sistema de plugins. É mais jovem que o HTTPie, então o ecossistema ao redor dele é menor. Ainda é um cliente, não um motor de asserções.

Hurl: testes em texto simples que rodam em CI

Hurl é onde esta lista passa de "enviar uma requisição" para "testar uma resposta". Ele executa requisições HTTP escritas em um arquivo `.hurl` em texto simples e faz asserções sobre os resultados. É escrito em Rust, alimentado por libcurl internamente, e é entregue como um único binário sem tempo de execução. Os testes são lidos quase como as próprias requisições, o que os torna fáceis de revisar em um pull request.

brew install hurl   # or: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # non-zero exit if an assertion fails

Melhor para: verificações de contrato e testes de fumaça que você mantém no controle de versão como texto legível. A flag `--test` o torna um controle de CI limpo; uma asserção falha retorna um código de saída diferente de zero. Limitação honesta: é focado em HTTP, então não irá suportar gRPC ou gerar carga real. Fluxos complexos significam mais arquivos `.hurl` em vez de uma linguagem de script.

Step CI: um arquivo YAML para um fluxo de várias etapas

Step CI executa workflows de API descritos em um único arquivo YAML. Ele cobre REST, GraphQL, gRPC, tRPC e SOAP em um único workflow, e pode validar contra um esquema OpenAPI. Você o instala via npm e executa o mesmo arquivo localmente e no CI. É bem legível quando um teste é realmente uma sequência: fazer login, capturar um token, usá-lo na próxima chamada, verificar o resultado.

npm install -g stepci

# workflow.yml describes steps, captures, and checks
stepci run workflow.yml

Melhor para: equipes que desejam um arquivo declarativo descrevendo um fluxo de API de várias etapas, executado identicamente em um laptop e em um pipeline. Limitação honesta: é um pacote Node, então é mais pesado que um binário Rust ou Go, e carrega um ambiente de execução. A cadência de lançamento diminuiu, então verifique a atividade recente do repositório antes de construir um pipeline sobre ele. Para saber como essas peças se encaixam em um plano de teste mais completo, consulte estratégias de teste de API.

k6: teste de carga leve a partir do terminal

k6 responde a uma pergunta diferente: não "esta resposta está correta", mas "ela aguenta sob carga". É escrito em Go, é entregue como um único binário estático e os scripts são JavaScript simples. É construído para uso mínimo de recursos, então você pode simular tráfego real a partir de um laptop. Limiares transformam um teste de carga em um controle de aprovação/reprovação; se um limite for violado, o k6 sai com o código 99, que um pipeline interpreta como falha.

brew install k6   # or run via Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

Melhor para: verificações de desempenho e carga que você deseja roteirizar e executar em CI sem precisar configurar um cluster. Limitação honesta: é uma ferramenta de carga, não um cliente de teste funcional; você não a usaria para inspecionar uma única resposta. Escrever cenários significativos significa aprender sua API JavaScript.

Newman: execute uma coleção Postman sem interface gráfica

Newman é o executor de linha de comando para coleções Postman. Se sua equipe já constrói requisições e testes no Postman, Newman executa essa mesma coleção a partir de um terminal sem GUI, o que é necessário em CI. Você exporta a coleção (e opcionalmente um ambiente) como JSON e aponta Newman para ela.

npm install -g newman

# collection.json exported from Postman; -e passes an environment
newman run collection.json -e staging.json

Melhor para: equipes que já utilizam o Postman e desejam que suas coleções existentes sejam executadas sem interface gráfica em um pipeline. Newman retorna um código de saída diferente de zero quando um teste falha, então ele controla o CI de forma limpa. Limitação honesta: é um pacote Node e executa apenas coleções no formato Postman, então é mais útil se você já estiver nesse ecossistema. Ele executa testes que alguém construiu em uma GUI; a autoria ainda acontece lá.

Apidog CLI: execute os cenários que você construiu, controle o CI pelo código de saída

A CLI do Apidog é a parte leve do Apidog. É um pacote npm, `apidog-cli`, que executa os cenários de teste que você projetou visualmente no Apidog diretamente de um terminal. A parte de construção do teste permanece na GUI, onde encadear requisições, extrair variáveis e escrever asserções é rápido; a CLI é a pequena peça que executa um desses cenários sem interface gráfica e lhe entrega um código de saída. O Apidog não é de código aberto, mas seu plano gratuito mais esta CLI oferece uma alternativa integrada para não precisar juntar um cliente, um executor e uma ferramenta de carga separados.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

Você não precisa adivinhar os IDs do cenário e do ambiente. Abra seu cenário de teste no Apidog, vá para a aba CI/CD e copie o comando `apidog run` gerado com os IDs já preenchidos. O reporter `-r cli` imprime um resultado passo a passo e um resumo no terminal; adicione `-r cli,junit` quando um dashboard de CI precisar analisar os resultados. Assim como as ferramentas acima, `apidog run` sai com `0` quando todas as asserções passam e com um valor diferente de zero quando algo falha, então um pipeline o trata como um controle limpo. Sua saída é um JSON estruturado com `agentHints.nextSteps`, o que facilita para um agente de codificação de IA executar e ler também.

Melhor para: equipes que desejam criar cenários complexos e de várias etapas em um editor visual, mas executá-los sem interface gráfica em CI ou a partir de um agente. Limitação honesta: ao contrário do curl ou xh, ele está vinculado a cenários que você mantém em um projeto Apidog, então é a opção de plataforma integrada, não um cliente HTTP puro. Para o conjunto completo de comandos, consulte o guia completo da CLI do Apidog, a referência de comando apidog run e o passo a passo sobre como testar uma API REST a partir da linha de comando com a CLI do Apidog.

Como escolher

A ferramenta certa depende de quão longe você precisa ir além de "enviar uma requisição".

Comece pelo topo para trabalho manual. Recorra ao curl ou xh para acessar um endpoint. Mude para Hurl quando quiser que essas verificações sejam executadas no controle de versão. Traga o k6 quando a questão for carga, e Newman se seus testes já estão no Postman. Escolha a CLI do Apidog quando preferir construir um cenário complexo em um editor e executá-lo sem interface gráfica em qualquer outro lugar. Se você está avaliando estas opções contra um workflow totalmente sem GUI, o guia de ferramentas de teste de API headless aborda a execução de testes sem nenhuma interface.

Onde ferramentas leves compensam

Ferramentas CLI leves se destacam nos mesmos dias em que uma GUI o atrasa: quando você está imerso em um terminal, quando um teste precisa ser executado em CI sem um humano, e cada vez mais quando um agente de IA executa a verificação para você. curl e xh mantêm o loop manual ágil. Hurl e Step CI transformam requisições ad-hoc em testes repetíveis. k6 responde à questão da carga. Newman executa o que você já construiu no Postman.

A CLI do Apidog preenche a lacuna entre construir um teste e executá-lo em qualquer lugar. Você projeta o cenário uma vez no Apidog, então `apidog run` o executa de um terminal, um pipeline ou um agente, e o código de saída decide se a build permanece verde. Baixe o Apidog, construa um cenário e insira seu comando `apidog run` na sua configuração de CI para ver o ciclo completo se fechar.