How to Test REST APIs in Your Browser — A Developer's Guide

O que é teste de API?

Todo aplicativo web e mobile moderno depende de APIs. Quando você carrega o feed do Twitter, faz um pedido na Amazon ou consulta a previsão do tempo no celular, por trás das telas ocorre uma chamada de API. Teste de API é a prática de enviar requisições a esses endpoints e verificar se as respostas estão corretas — o código de status adequado, o formato de dados esperado e um desempenho razoável.

Diferente do teste de interface, o teste de API atinge a camada abaixo da UI. Ele encontra bugs mais cedo, roda mais rápido e cobre cenários difíceis de reproduzir com um clique no navegador. Seja construindo sua própria API ou integrando com um serviço de terceiros, saber testar endpoints com agilidade é uma habilidade fundamental para desenvolvedores.

Métodos HTTP explicados

APIs REST usam métodos HTTP padrão para indicar a ação sobre um recurso. Referência rápida:

Método	Finalidade	Tem corpo
GET	Obter um recurso ou uma coleção	Não
POST	Criar um novo recurso	Sim
PUT	Substituir um recurso por completo	Sim
PATCH	Atualizar parcialmente um recurso	Sim
DELETE	Remover um recurso	Raramente

Diferença importante: PUT substitui o recurso inteiro — qualquer campo que você omitir será removido. PATCH atualiza apenas os campos que você incluir no corpo da requisição. A maioria das APIs que aceita atualizações usa PATCH para alterações parciais e PUT para substituição completa.

Como testar APIs no navegador

Você não precisa instalar o Postman nem decorar flags do cURL para testar uma API. O Explorador de API no JSONTech.net permite enviar requisições no modo Navegador para APIs com CORS aberto ou mudar para o modo Proxy quando o navegador bloquear a requisição. Veja como:

1. Abra a ferramenta Explorador de API.
2. Selecione o método HTTP (GET, POST, PUT, PATCH ou DELETE) no menu suspenso.
3. Informe a URL do endpoint. Por exemplo: https://jsonplaceholder.typicode.com/posts/1
4. Adicione os cabeçalhos necessários (como Content-Type ou Authorization).
5. Se o método exigir corpo (POST, PUT, PATCH), digite o payload JSON no editor de corpo.
6. Clique em Enviar e analise a resposta — código de status, cabeçalhos e o corpo JSON formatado.

Se o navegador mostrar um erro de CORS, troque o Explorador de API para o modo Proxy. Assim, a requisição real passa pela infraestrutura de borda da JSONTech e você pode continuar testando sem sair da página.

Exemplo: buscar um post

GET https://jsonplaceholder.typicode.com/posts/1

Response (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\\nsuscipit recusandae consequuntur..."
}

Exemplo: criar um post

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Response (201 Created):
{
  "id": 101,
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Entendendo cabeçalhos de requisição

Os cabeçalhos carregam metadados sobre a requisição. Eles informam ao servidor qual formato você espera, quem você é e como a conexão deve se comportar. Os que você mais vai usar:

Cabeçalho	Finalidade	Exemplo de valor
Content-Type	Formato do corpo da requisição	application/json
Accept	Formato desejado na resposta	application/json
Authorization	Credenciais de autenticação	Bearer eyJhbGciOi...
Cache-Control	Diretivas de cache	no-cache
User-Agent	Identifica o aplicativo cliente	MyApp/1.0

Esquecer Content-Type: application/json em requisições POST/PUT é uma das causas mais comuns de APIs retornarem 400 Bad Request. Sem isso, o servidor não sabe como interpretar o corpo.

Métodos de autenticação

A maioria das APIs em produção exige autenticação. Os três padrões que você mais encontra:

Bearer Token (JWT)

A abordagem mais comum em APIs modernas. Você inclui um token no cabeçalho Authorization:

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

Autenticação básica

Codifica usuário e senha em uma string Base64. Simples, mas segura apenas sobre HTTPS:

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

Chave de API (API Key)

Algumas APIs usam um cabeçalho customizado ou um parâmetro de query para uma chave estática:

// As a header
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// As a query parameter
GET https://api.example.com/data?api_key=sk_live_abc123def456

Lendo respostas de API

Ao enviar uma requisição, a resposta mostra exatamente o que aconteceu. Você precisa ler três coisas: o código de status, os cabeçalhos da resposta e o corpo.

Códigos de status

Código	Significado	Quando aparece
200	OK	GET, PUT, PATCH ou DELETE bem-sucedidos
201	Criado	POST bem-sucedido que criou um recurso
400	Requisição inválida	JSON inválido, campos obrigatórios ausentes, tipos errados
401	Não autorizado	Token de autenticação ausente ou expirado
403	Proibido	Credenciais válidas, mas permissões insuficientes
404	Não encontrado	O endpoint ou o recurso não existe
500	Erro interno do servidor	Falha no lado do servidor

Cabeçalhos de resposta

Preste atenção a cabeçalhos como Content-Type (confirma o formato da resposta), X-RateLimit-Remaining (quantas requisições ainda restam) e Retry-After (quando tentar de novo após atingir o limite de taxa).

Corpo JSON

O corpo da resposta é onde estão os dados. Uma API bem desenhada costuma encapsulá-los em uma estrutura consistente:

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

Quando algo dá errado, você recebe um objeto de erro em vez de um objeto de dados. Sempre verifique o código de status primeiro e interprete o corpo em seguida.

CORS: o que é e por que aparecem erros

Cross-Origin Resource Sharing (CORS) é um mecanismo de segurança do navegador. Quando seu JavaScript em localhost:3000 tenta chamar uma API em api.example.com, o navegador bloqueia a requisição a menos que o servidor permita explicitamente via cabeçalhos CORS.

O erro típico se parece com:

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

Isso não é um bug no seu código — é o navegador aplicando segurança. A correção precisa vir do lado do servidor. Soluções comuns:

• Pedir ao dono da API para incluir sua origem no cabeçalho Access-Control-Allow-Origin.
• Usar um proxy — encaminhar requisições pelo seu próprio backend (por exemplo, uma rota de API no Next.js ou um servidor Express simples) para contornar a restrição de origem cruzada.
• Usar uma ferramenta no navegador com opção de proxy como o Explorador de API. Comece no modo Navegador para APIs abertas e mude para o modo Proxy quando precisar que a JSONTech encaminhe a requisição para teste.

CORS afeta apenas navegadores. Ferramentas como cURL, Postman e código no servidor não estão sujeitas a restrições de CORS — elas não rodam dentro da sandbox do navegador.

Erros comuns em teste de API

Armadilhas que pegam desenvolvedores — de iniciantes a engenheiros experientes em APIs desconhecidas:

1. Esquecer o cabeçalho Content-Type. Enviar um corpo JSON sem Content-Type: application/json faz a maioria dos servidores rejeitar ou interpretar mal a requisição.
2. Usar GET quando o correto é POST. Requisições GET não devem ter corpo. Se você está enviando dados, precisa de POST, PUT ou PATCH.
3. Ignorar códigos de status. Um 200 com mensagem de erro no corpo não é sucesso. Sempre confira o código HTTP real.
4. Embutir credenciais na URL. Nunca coloque chaves ou tokens na query string se puder usar cabeçalhos — URLs acabam em logs de servidor, histórico do navegador e cabeçalho Referer.
5. Testar só o caminho feliz. Envie JSON inválido, corpos vazios, campos obrigatórios ausentes e tokens inválidos para ver como a API trata erros de fato.
6. Não verificar limites de taxa. Muitas APIs retornam 429 quando você ultrapassa o limite. Monitore proativamente cabeçalhos como X-RateLimit-Remaining.
7. Confundir erro de CORS com erro de servidor. Erro de CORS significa que o navegador bloqueou a requisição — o servidor pode ter respondido com sucesso, mas o navegador se recusou a mostrar o resultado.

Experimente você mesmo

Pronto para testar uma API? Abra o Explorador de API e envie uma requisição GET para https://jsonplaceholder.typicode.com/users/1. Você verá a resposta completa — código de status, cabeçalhos e corpo JSON formatado — e, se outra API for bloqueada por CORS, poderá tentar de novo no modo Proxy.

Sem downloads, sem cadastro, sem configuração. Escolha o método, informe a URL e clique em Enviar.