Testador de API REST
Ferramenta para testar APIs REST.
Requisição
Resposta
| Status | {{ status }} |
|---|---|
| Cabeçalhos | {{ hkey }}: {{ hval }} |
* Não é possível recuperar dados a menos que a API adicione o cabeçalho 'Access-Control-Allow-Origin': *. Considere usar a extensão correspondente no Google Chrome.
https://chromewebstore.google.com/detail/cors-unblock/lfhmikememgdcahcdlaciloancbhjino
O que é um testador de API REST?
Um testador de API REST permite escolher um método HTTP (GET, POST, PUT, DELETE e assim por diante), enviar uma requisição a um endpoint pelo navegador e inspecionar na hora o código de status, os cabeçalhos e o corpo da resposta. Assim você verifica o comportamento de uma API sem instalar um aplicativo de desktop como o Postman nem recorrer ao cURL na linha de comando.
Serve para conferir o comportamento enquanto você desenvolve uma API, ou para sondar uma API pública e conhecer a forma das suas respostas antes mesmo de ler a documentação. Tenha em mente, porém, que como as requisições partem direto do navegador, você não receberá resposta se a API de destino não permitir CORS (o cabeçalho Access-Control-Allow-Origin).
Como usar o testador de API REST
- Selecione o método HTTP Escolha o método correspondente à operação desejada: GET, POST, PUT, PATCH, DELETE e assim por diante.
- Informe a URL do endpoint Indique a URL da API que está consultando. Forneça uma URL completa começando por https.
- Defina cabeçalhos e corpo se preciso Informe cabeçalhos como um token de autenticação ou Content-Type, e o corpo JSON que envia com POST ou PUT.
- Envie e inspecione a resposta O código de status, os cabeçalhos e o corpo da resposta são exibidos ali mesmo.
Dicas para aproveitar melhor
- Devido às restrições de CORS, não é possível fazer requisições diretas a APIs sem o cabeçalho
Access-Control-Allow-Origin. Use APIs públicas ou APIs com CORS habilitado. - Defina
Content-Type: application/jsonnos cabeçalhos da requisição para enviar um corpo JSON. - Códigos de status HTTP: 2xx=sucesso, 4xx=erro do cliente (401=não autorizado, 404=não encontrado), 5xx=erro do servidor.
- Para APIs que exigem autenticação Bearer Token, adicione
Authorization: Bearer {token}nos cabeçalhos.
Quando um testador de API REST é útil
Conferir uma API em desenvolvimento
Veja de imediato se a API de back-end que você está construindo retorna a resposta esperada, enquanto ainda a está escrevendo.
Investigar a forma das respostas de uma API pública
Antes de ler a documentação de um serviço externo, envie uma requisição real e observe a estrutura JSON que volta.
Verificar os cabeçalhos de autenticação
Teste se uma requisição que leva um token Bearer ou uma chave de API é autenticada corretamente.
Ver o que uma resposta de erro contém
Envie de propósito um parâmetro inválido e confira qual mensagem de erro e qual código de status a API retorna.
Glossário
- REST
- Sigla de Representational State Transfer. Um estilo de projeto de API web em que os recursos são manipulados por métodos HTTP e URLs.
- CORS
- Sigla de Cross-Origin Resource Sharing. O mecanismo pelo qual os navegadores restringem requisições a outra origem (domínio): enquanto o servidor da API não devolver o cabeçalho que permite, a resposta não pode ser lida.
- Endpoint
- A URL na qual uma API aceita requisições. Por exemplo «/api/users», que indica o recurso sobre o qual se opera.
- Método HTTP
- O identificador que informa o tipo de requisição. Entre eles estão GET (obter), POST (criar), PUT (atualizar) e DELETE (remover).
- Token Bearer
- Um formato de token muito usado na autenticação de APIs. É anexado ao cabeçalho da requisição na forma «Authorization: Bearer {token}».
Perguntas frequentes
Access-Control-Allow-Origin, o navegador irá bloqueá-la. Use uma API pública ou com CORS habilitado, ou instale uma extensão como CORS Unblock.Content-Type: application/json aos cabeçalhos da requisição e insira uma string JSON válida no campo do corpo antes de enviar.Authorization: Bearer {your_token} aos cabeçalhos da requisição, substituindo {your_token} pelo valor real do seu token.
Curiosidade — O nascimento do REST: como a tese de doutorado de Roy Fielding transformou o desenvolvimento web
O REST foi proposto em 2000 por Roy Fielding em sua tese de doutorado "Architectural Styles and the Design of Network-based Software Architectures". Fielding foi um dos principais coautores da especificação HTTP/1.1, e o conceito de REST surgiu enquanto ele organizava os princípios de design por trás do HTTP.
O Twitter migrou do SOAP para a API REST por volta de 2010 e a abriu para os desenvolvedores, impulsionando sua adoção massiva. Hoje, serviços como Stripe, GitHub, Slack e OpenAI (ChatGPT) oferecem APIs REST, formando o que é chamado de "economia de APIs".
O design original do REST inclui a restrição "Hypermedia as the Engine of Application State (HATEOAS)", mas pouquíssimos serviços a implementam de forma rigorosa. O debate sobre "o que realmente é RESTful" ressurge periodicamente na comunidade de desenvolvimento web, e a definição permanece controversa.