Existem inúmeras e variadas opções para o teste de APIs REST. O caminho mais simples (porém limitado) seria a condução de validações via browser.
Soluções como Postman facilitam muito esse tipo de tarefa, contando com interfaces gráficas intuitivas e que auxiliam Desenvolvedores a configurar/identificar rapidamente os diferentes elementos relacionados a uma solicitação HTTP (headers, tokens, body, códigos de retorno HTTP).
Apesar de todos esses aspectos positivos, a execução de alguns tipos de testes com estas ferramentas pode se revelar um processo trabalhoso:
- No caso de validações envolvendo APIs protegidas com JWT (JSON Web Tokens), uma primeira requisição para obter o token deverá ser realizada e solicitações subsequentes precisarão que este item (token) seja informado no header a cada envio;
- Estes procedimentos certamente exigirão bastante interação manual do usuário em questão, com cliques em diversos campos e copiando/colando/preenchendo valores.
Uma outra alternativa seria a implementação de classes e/ou programas para testes. Embora funcional, essa tarefa pode exigir a instalação de pacotes/bibliotecas, implementação de tipos para manipulação de informações, etc.
Em muitas situações tais testes acabariam resultando em um código extenso, contribuindo pouco para uma maior agilidade nas validações.
Comumente associado a tarefas de administração de recursos/sistemas, o PowerShell também pode ser usado na validação de APIs REST. E o melhor, com pouco esforço de codificação e facilitando a montagem de roteiros de testes constituídos por várias ações em sequência.
Vale lembrar ainda que o PowerShell é uma solução multiplataforma compatível com ambientes Windows, Linux e macOS. Além disso, conta com uma linguagem para criação de scripts bastante simples e capaz de ser compreendida/assimilada rapidamente.
A implementação de scripts pode acontecer a partir do Visual Studio Code, através de uma extensão gratuita com capacidade até mesmo de debugging syntax, highlighting e autocomplete.
Neste artigo irei demonstrar a implementação de um script de testes, utilizando para isso uma API REST implementada em ASP.NET Core 2.2 e que emprega JWT (abaixo está o repositório no GitHub da mesma):
Um pouco mais sobre o teste de APIs REST com o PowerShell pode ser encontrado nos slides de uma apresentação que realizei recentemente (juntamente com meu amigo Ewerton Rodrigues Jordão):
E nos scripts que estão no seguinte repositório:
Configurando o Visual Studio Code para uso do PowerShell.
Na imagem a seguir é possível observar a extensão do PowerShell já instalada no Visual Studio Code:
O ícone do PowerShell aparecerá à esquerda no VS Code, assim como um terminal, na porção inferior:
A próxima imagem traz um exemplo de execução (via tecla F5) com debugging de um script PowerShell no Visual Studio Code:
Implementando e executando os testes
Na listagem a seguir está o script que permitirá o teste da API REST mencionada anteriormente:
- A instrução [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 permitirá o acesso à API REST executada localmente, a qual faz uso de um certificado de desenvolvimento (um erro de segurança aconteceria sem a presença deste comando);
- Variáveis estão declaradas com seus respectivos nomes iniciando por $ (cifrão);
- Na variável $credenciais foi declarado um objeto com as credenciais do usuário, com o mesmo sendo convertido para JSON via instrução ConvertTo-Json;
- A instrução $credenciais (linha 13) exibirá em tela o conteúdo associado à variável de mesmo nome;
- Uma primeira requisição será enviada ao projeto em execução via instrução Invoke-RestMethod (linha 15), a fim de obter o token para acesso à API de produtos. Foram informados neste comando a URL de destino, o método HTTP utilizado (POST), o formato do conteúdo que está sendo manipulado (application/json) e os dados do corpo/body da requisição (conteúdo JSON vinculado a $credenciais). O resultado será então associado a $retornoLogin;
- Com o PowerShell podemos manipular de forma bastante simplificada (sem a necessidade de codificação de classes) as propriedades de um objeto JSON, como exemplificado na linha 19 em que a propriedade authenticated de $retornoLogin está sendo utilizada numa checagem;
- O objeto representado pela variável $header (linha 23) receberá em Authorization o conteúdo do token, sendo necessário concatenar também no início da string a palavra Bearer (Bearer Authentication, um dos termos utilizados para autenticação via JWT). Este valor será utilizado nas chamadas subsequentes à API de produtos via Invoke-RestMethod;
É possível notar ainda o envio de duas requisições do tipo POST para cadastramento de itens, além de uma última solicitação GET para consulta ao cadastro de produtos.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# O projeto utilizada nestes testes está em: https://github.com/renatogroffe/ASPNETCore2.1_ApiController
$urlBase = "https://localhost:5001/api/"
$credenciais = @{
UserID = "admin_apiprodutos"
Password = "AdminAPIProdutos01!"
} | ConvertTo-Json
$credenciais
$retornoLogin = Invoke-RestMethod -Uri ($urlBase + "login") -Method POST -ContentType "application/json" -Body $credenciais
$retornoLogin
if ($retornoLogin.authenticated) {
$url_API_Produtos = ($urlBase + "produtos")
$headers = @{
Authorization = "Bearer " + $retornoLogin.accessToken
}
$headers
$produto1 = @{
CodigoBarras = "00001"
Nome = "Teste Produto 01"
Preco = 100.01
} | ConvertTo-Json
$retornoProduto = Invoke-RestMethod -Uri $url_API_Produtos -Headers $headers -Method POST -ContentType "application/json" -Body $produto1
$retornoProduto
$produto2 = @{
CodigoBarras = "00002"
Nome = "Teste Produto 02"
Preco = 22.2
} | ConvertTo-Json
$retornoProduto = Invoke-RestMethod -Uri $url_API_Produtos -Headers $headers -Method POST -ContentType "application/json" -Body $produto2
$retornoProduto
$consultaProdutos = Invoke-RestMethod -Uri $url_API_Produtos -Headers $headers -Method GET -ContentType "application/json"
$consultaProdutos
}
As próximas imagens trazem o resultado da execução deste script via PowerShell: