Testador de Requisição API

Cliente REST no navegador — GET/POST/PUT/PATCH/DELETE, cabeçalhos personalizados, body JSON/XML, timing de resposta. Postman leve para debug de APIs.

Tem feedback? Reporte bugs, sugira recursos ou compartilhe suas ideias — lemos todos

Testador de Requisição API - Teste APIs REST Online

Toda integração de API começa do mesmo jeito: leia a documentação, envie uma requisição de teste feita à mão, inspecione a resposta, depois escreva o código de produção apenas após confirmar o contrato. Por décadas esse fluxo de trabalho significou Postman, Insomnia, curl ou HTTPie — todos os quais requerem instalar software. Esta ferramenta coloca o mesmo fluxo dentro de uma aba do navegador para que você possa atingir um endpoint rápido sem deixar seu contexto atual de desenvolvimento. Suporta todo verbo HTTP padrão (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), aceita cabeçalhos arbitrários em forma JSON limpa (tokens Bearer de Authorization, X-API-Key, Content-Type, Accept-Language, cabeçalhos corporativos personalizados), envia bodies JSON/XML/form-encoded/raw text, e mostra tudo que volta: código de status numérico com a frase de razão padrão, cada cabeçalho de resposta parseado e rotulado, o body pretty-printed se parseia como JSON ou mantido raw caso contrário, o tempo round-trip em milissegundos, e o comprimento em bytes da resposta. A pegadinha mais comum para teste de API no navegador é CORS — APIs públicas projetadas para uso no navegador (Stripe, GitHub, OpenAI, JSONPlaceholder) funcionam bem, mas APIs internas que só esperam tráfego servidor-para-servidor bloquearão a requisição com um cabeçalho Access-Control-Allow-Origin faltando. Quando isso acontece, a mensagem de erro diz exatamente o que procurar na configuração CORS do seu servidor API.

O que é um Testador de Requisição API?

Um Testador de Requisição API é uma ferramenta que permite enviar requisições HTTP para APIs e visualizar suas respostas. É essencial para:

- Testar endpoints de API durante desenvolvimento
- Depurar problemas de API
- Explorar APIs de terceiros
- Verificar autenticação e autorização
- Testar diferentes métodos HTTP
- Verificar formatos de resposta de API

Age como um cliente que pode se comunicar com qualquer API REST, similar a ferramentas como Postman ou Insomnia.

Como testar uma API?

Testar uma API é simples:

1. Digite a URL do endpoint da API
2. Selecione o método HTTP (GET, POST, PUT, DELETE, PATCH)
3. (Opcional) Adicione cabeçalhos personalizados em formato JSON
4. (Opcional) Adicione corpo de requisição para requisições POST/PUT/PATCH
5. Clique em 'Enviar Requisição'
6. Visualize o status de resposta, cabeçalhos, corpo e tempo

Exemplo de requisição GET:
URL: https://jsonplaceholder.typicode.com/users/1
Método: GET

Exemplo de requisição POST:
URL: https://jsonplaceholder.typicode.com/posts
Método: POST
Corpo: {"title": "Teste", "body": "Conteúdo", "userId": 1}

Quais métodos HTTP são suportados?

Esta ferramenta suporta todos os métodos HTTP padrão:

- GET: Recuperar dados do servidor
- POST: Enviar dados para criar novos recursos
- PUT: Atualizar recursos existentes completamente
- PATCH: Atualizar parcialmente recursos existentes
- DELETE: Remover recursos
- HEAD: Obter apenas cabeçalhos (sem corpo)
- OPTIONS: Verificar métodos suportados

A maioria das APIs usa GET (ler), POST (criar), PUT/PATCH (atualizar) e operações DELETE.

Como adicionar cabeçalhos personalizados?

Cabeçalhos devem ser adicionados em formato JSON válido:

{
"Content-Type": "application/json",
"Authorization": "Bearer seu-token-aqui",
"X-Custom-Header": "valor"
}

Cabeçalhos comuns:
- Content-Type: Especifica formato do corpo da requisição (application/json, text/xml)
- Authorization: Tokens de autenticação (Bearer, Basic, chaves API)
- Accept: Formato de resposta esperado
- User-Agent: Identificação do cliente
- X-API-Key: Autenticação por chave API

Cabeçalhos são pares chave-valor que fornecem metadados sobre a requisição.

E sobre erros de CORS?

CORS (Compartilhamento de Recursos entre Origens) é um recurso de segurança do navegador que pode bloquear requisições de API desta ferramenta:

- Muitas APIs não permitem requisições de navegadores
- Este é um comportamento de segurança normal
- APIs públicas frequentemente têm CORS habilitado
- APIs privadas podem bloquear requisições do navegador

Soluções:
- Use APIs que suportam CORS
- Teste com extensões do navegador que desabilitam CORS (apenas para testes)
- Use ferramentas backend para testes em produção
- Contate provedores de API para habilitar CORS

Para testes sérios de API, considere usar ferramentas dedicadas como Postman, Insomnia ou frameworks de teste backend.

Quando usar PUT vs PATCH vs POST para atualizar um recurso?

Esses três verbos parecem intercambiáveis para iniciantes mas têm semânticas distintas que determinam a correção da API e o comportamento de cache. POST CRIA um NOVO recurso no servidor (ou dispara uma ação com efeitos colaterais) — o servidor escolhe o ID do novo recurso e retorna sua localização. Use para /users ao registrar novo usuário, /orders ao fazer pedido, /search ao executar busca que modifica estado do servidor. PUT SUBSTITUI um recurso existente inteiro em uma URL conhecida — você envia a representação nova completa, e qualquer campo omitido é resetado para null/default. Use ao atualizar o objeto perfil completo de usuário em /users/123. PATCH modifica parcialmente um recurso existente — você envia apenas os campos que mudam, deixando outros intactos. Use ao mudar apenas o campo email em /users/123. A spec HTTP diz que PUT e PATCH devem ser IDEMPOTENTES (chamar o mesmo PUT/PATCH duas vezes produz o mesmo estado final), enquanto POST não precisa ser (dois POSTs para /orders criam dois pedidos). Erre isso e clientes vão tentar novamente POSTs falhados e acidentalmente criar registros duplicados.

Testador de Requisição API — Cliente REST no navegador — GET/POST/PUT/PATCH/DELETE, cabeçalhos personalizados, body JSON/XML, timing de resposta. Pos — **Testador de Requisição API**

Como envio um token Bearer Authorization corretamente?

Autenticação Bearer é o padrão dominante de auth de API em 2026 — usado pelo OAuth 2.0, OpenID Connect, APIs baseadas em JWT, e a maioria das plataformas SaaS modernas. O formato é fixo pela RFC 6750: o valor do cabeçalho Authorization DEVE ser a palavra literal 'Bearer' seguida por exatamente um espaço e a string do token. No campo Headers desta ferramenta, cole:

{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}

Erros comuns: (1) Esquecer o espaço após 'Bearer' — APIs retornam 401. (2) Usar minúscula 'bearer' — RFC diz insensível a maiúsculas mas alguns servidores estritos rejeitam. (3) Incluir os colchetes '<' '>' de exemplos de documentação literalmente no token. (4) Enviar o token bruto sem prefixo 'Bearer' — esse é o padrão Basic auth mais antigo. (5) Reutilizar um JWT expirado — decodifique em jwt.io para verificar a claim 'exp'. Nunca cole tokens de produção vivos em ferramentas não confiáveis; este testador roda inteiramente no seu navegador mas você ainda deve rotacionar qualquer token usado para debug ao terminar.

O que significam os códigos de status HTTP comuns (200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503)?

O código de status é a primeira coisa a ler em qualquer resposta — ele informa o resultado antes mesmo de você olhar o corpo.

2xx sucesso:
- 200 OK: a requisição teve sucesso, o corpo contém o resultado.
- 201 Created: um POST criou um novo recurso; verifique o cabeçalho Location para sua URL.
- 204 No Content: sucesso com corpo vazio (comum em DELETE e alguns PUT/PATCH).

3xx redirecionamento:
- 301 Moved Permanently: o recurso tem nova URL — atualize seu endpoint.
- 302/307/308: redirecionamentos temporários ou que preservam o método.

4xx erro do cliente (sua requisição está errada):
- 400 Bad Request: sintaxe malformada ou parâmetros inválidos.
- 401 Unauthorized: autenticação ausente ou inválida — verifique seu cabeçalho Authorization / token.
- 403 Forbidden: autenticado mas sem permissão (permissões/escopos).
- 404 Not Found: URL errada ou o recurso não existe.
- 422 Unprocessable Entity: o corpo foi parseado mas falhou nas regras de validação.
- 429 Too Many Requests: limite de taxa atingido — aguarde e verifique o cabeçalho Retry-After.

5xx erro do servidor (o servidor falhou):
- 500 Internal Server Error: uma exceção não tratada no servidor.
- 503 Service Unavailable: servidor sobrecarregado ou em manutenção; tente novamente mais tarde.

Regra prática: 4xx significa corrija sua requisição, 5xx significa que a culpa é do servidor.

Preciso definir um cabeçalho Content-Type ao enviar um corpo de requisição?

Sim — quando você envia um corpo, o servidor usa o Content-Type para decidir como parseá-lo, e errar é uma das causas mais comuns de uma resposta 400 ou 415.

- Corpo JSON: defina Content-Type como application/json. A maioria das APIs JSON rejeita ou ignora silenciosamente um corpo enviado sem ele. O corpo deve ser JSON válido, ex. {"name":"Ada"}.
- Dados de formulário: defina application/x-www-form-urlencoded e envie key=value&key2=value2 (o formato clássico de formulários HTML).
- Texto puro/XML: use text/plain ou application/xml/text/xml para que o servidor não tente parseá-lo como JSON.
- Upload de arquivos: use multipart/form-data (nota: os limites multipart reais são mais fáceis a partir do curl/Postman nativo do que de um campo de texto bruto).

Para GET, HEAD, OPTIONS e DELETE sem corpo, você não precisa de Content-Type. Lembre também que o cabeçalho Accept é o espelho do Content-Type: ele diz ao servidor qual formato você quer de volta (ex. Accept: application/json).

Como funciona o recurso Copiar como cURL?

Após enviar uma requisição, clique em 'Copiar como cURL' para copiar um comando curl pronto para executar que reproduz exatamente o que a ferramenta acabou de enviar — mesma URL, mesmo método -X, um flag -H por cabeçalho, e um flag --data para o corpo. Cole em qualquer terminal, relatório de bug, runbook ou script de CI.

Esta é a saída de emergência mais útil do navegador. Como os navegadores aplicam CORS, algumas APIs que bloqueiam este testador no navegador funcionarão perfeitamente a partir do curl, que não tem política de mesma origem. Então, quando bater num muro CORS, converta a requisição para curl e execute-a do seu terminal ou servidor para confirmar que a própria API funciona.

O comando gerado coloca aspas simples e escapa a URL, os cabeçalhos e o corpo para que valores com espaços ou caracteres especiais permaneçam intactos. É simples, sem dependências e portável para qualquer shell, tornando-se o formato universal de intercâmbio entre este testador, seus colegas e sua automação.

Meus dados estão seguros?

Considerações de privacidade:

- Requisições vão diretamente do seu navegador para a API
- Nenhum dado passa pelos nossos servidores
- Não registramos ou armazenamos quaisquer dados de requisição/resposta
- Seja cauteloso com dados sensíveis (senhas, tokens)
- Evite testar com credenciais de produção
- Considere usar endpoints de API de teste/sandbox

Dicas de segurança:
- Não compartilhe chaves de API publicamente
- Use credenciais específicas de ambiente
- Teste com dados fictícios quando possível
- Revogue tokens de teste após uso