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.

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**

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.

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.

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