16 09 2015

Uma das principais características que eu tento manter nas publicações desse site é a simplicidade nos exemplos. Muitas vezes, quando estamos com alguma dúvida durante o desenvolvimento de um aplicativo e procuramos a solução na Internet, encontramos artigos onde o autor não lembra que do outro lado do monitor pode ser que esteja uma pessoa que não tem tanta experiência quanto ele. É por isso que, quando eu escrevo qualquer artigo que seja, eu considero que o leitor é iniciante e que sabe muito pouco sobre o tema sendo abordado.

Mas, o que é que isso tem a ver com o tema desse artigo? É o seguinte. Na época que eu estava escrevendo o meu artigo sobre live tiles para a revista .NET Magazine, eu precisei retornar obrigatoriamente XML em um Controller da Web API e, consequentemente, precisei utilizar o Fiddler para debugar essa API. Se você não sabe, durante grande parte da minha carreira eu trabalhei somente com projetos desktop. A minha experiência com desenvolvimento web é muito pequena, então, quando abri o Fiddler pela primeira vez, fiquei assustado. E os artigos que você encontra na Internet sobre ele também não ajudam muito. Dessa forma, depois que eu aprendi como utilizá-lo para esse propósito, resolvi escrever esse artigo para ajudar os leitores que tiverem que debugar Web API com o Fiddler.

Criando um exemplo de Web API

Antes de nos assustarmos com o Fiddler, vamos criar um exemplo muito simples de Web API para utilizarmos nesse artigo. Para isso, crie um novo projeto do tipo “ASP.NET Web Application” e escolha o tipo “Web API“:

No projeto criado, vá até a pasta “Models” e adicione uma nova classe chamada “Pessoa“, que terá somente as propriedades “ID“, “Nome” e “Sobrenome“:

    public class Pessoa
    {
        public int ID { get; set; }
        public string Nome { get; set; }
        public string Sobrenome { get; set; }
    }

Feito isso, adicione um novo Controller (chamado “PessoaController“) que deverá expor métodos para listarmos, criarmos, atualizarmos e excluirmos pessoas:

    public class PessoaController : ApiController
    {
        private static List<Models.Pessoa> _pessoas = new List<Models.Pessoa>();

        // GET: api/Pessoa
        public IEnumerable<Models.Pessoa> Get()
        {
            return _pessoas;
        }

        // GET: api/Pessoa/5
        public Models.Pessoa Get(int id)
        {
            return _pessoas.FirstOrDefault(pessoa => pessoa.ID.Equals(id));
        }

        // POST: api/Pessoa
        public void Post([FromBody]Models.Pessoa value)
        {
            _pessoas.Add(value);
        }

        // PUT: api/Pessoa/5
        public void Put(int id, Models.Pessoa value)
        {
            var pessoa = Get(id);
            if (pessoa != null)
            {
                pessoa.Nome = value.Nome;
                pessoa.Sobrenome = value.Sobrenome;
            }
        }

        // DELETE: api/Pessoa/5
        public void Delete(int id)
        {
            var pessoa = Get(id);
            if (pessoa != null)
                _pessoas.Remove(pessoa);
        }
    }

Note que o código do Controller é muito simples. Basicamente temos uma lista estática que armazenará as pessoas. No método “Get” nós retornamos a lista de pessoas. No método “Get” que recebe o “ID“, nós encontramos e retornamos a pessoa que tiver o “ID” informado. No método “Post” nós adicionamos a nova pessoa na lista. No método “Put” nós encontramos a pessoa com o “ID” informado e atualizamos o seu nome e sobrenome. E, finalmente, no método “Delete“, nós encontramos e removemos a pessoa da lista interna.

Obviamente, em uma aplicação real, o Controller seria muito mais complexo, mas, lembre-se que o foco desse artigo é mostrar como debugar Web API com o Fiddler. Para isso, esse simples exemplo dá e sobra!

Instalando o Fiddler

Como você pode conferir na página do Fiddler na Wikipedia, ele foi criado em 2003 pelo desenvolvedor chamado Eric Lawrence, enquanto ele ainda trabalhava na Microsoft. Em 2012, a Telerik comprou o Fiddler e, por consequência, o Eric Lawrence passou a trabalhar na Telerik fazendo a manutenção do Fiddler em tempo integral. Dito isso, você pode baixar a versão mais nova do Fiddler no site da Telerik.

Primeiras impressões

Posso ser sincero? A princípio, a interface do Fiddler assusta bastante:

Trocentos botões e tabs, uma lista de endereços que não para de crescer (caso você esteja navegando ou baixando alguma coisa), sinceramente, não está entre as melhores interfaces. Mas, não se preocupe. Vou te mostrar exatamente o que você vai precisar configurar para debugar sua Web API com o Fiddler!

Filtrando a lista de requests

Antes de configurarmos o Fiddler para que ele exiba somente os requests da nossa Web API, precisamos rodar o projeto de exemplo para descobrir a porta que será utilizada pelo IIS Express. No meu caso, foi a porta 58291:

Com esse número de porta em mãos, vamos configurar o Fiddler para que ele exiba somente os requests desse endereço. Para isso, vá até a aba “Filters” do Fiddler, marque a opção “Use Filters“, escolha a opção “Show only the following Hosts” e digite o endereço da sua Web API na caixa de texto (no meu caso “localhost:58291“):

Feito isso, a lista de requests no canto esquerdo da interface do Fiddler passará a listar somente os requests relacionados à nossa Web API. Dica extra: para limpar a lista de requests, clique nela e pressione as teclas CTRL + X.

Executando um POST

Quando executamos o nosso projeto, a nossa lista de pessoas estará vazia. Dessa forma, o melhor que podemos fazer para começar a explorar o Fiddler é executarmos um comando POST para adicionarmos uma nova pessoa. Para isso, vá até a aba “Composer“, escolha o método “POST” e digite o endereço do Controller “Pessoa” (no meu caso, “http://localhost:58291/api/pessoa“).

Além disso, como estamos fazendo um POST, precisamos informar no “Request Body” a representação em JSON da pessoa que deverá ser inserida na nossa lista:

{
"id":1,
"nome":"Andre",
"sobrenome":"Lima"
}

Clique em “Execute” e veja que a lista de requests à esquerda mostra o resultado da nossa requisição (um erro 415). Dê um duplo clique no erro para sabermos maiores detalhes do que aconteceu:

O erro, como você pode ver, é “Unsupported Media Type“. Isso aconteceu porque nós não definimos no cabeçalho do request o tipo de dados que estamos mandando junto com a requisição. Sem essa informação, a Web API não sabe o que fazer com o conteúdo que mandamos. Dessa forma, nesse caso precisamos definir um “Content-Type” no cabeçalho do request, informando que estamos enviando um JSON com a requisição (“Content-Type: application/json“):

Execute novamente o request e veja que, dessa vez, ele é executado sem erros. Agora inclua mais umas duas ou três pessoas com IDs e nomes diferentes para você treinar um pouco.

Por padrão, a Web API suporta nativamente os formatos JSON e XML. Portanto, você pode também alterar o “Content-Type” para “application/xml” e enviar um XML com a representação da pessoa. Você só precisa se atentar ao fato que é obrigatório especificarmos o namespace da classe “Pessoa” dentro do XML (no meu caso, “TesteWebAPI.Models“), caso contrário a Web API não conseguirá fazer o parse do XML e a instância de Pessoa recebida no método POST será null:

<Pessoa xmlns="http://schemas.datacontract.org/2004/07/TesteWebAPI.Models">
  <ID>2</ID>
  <Nome>Fulano</Nome>
  <Sobrenome>de Tal</Sobrenome>
</Pessoa>

Lembre-se que breakpoints funcionam normalmente enquanto estivermos em modo debug:

Executando um GET

Agora que já temos algumas pessoas incluídas na nossa lista, podemos efetuar um GET para obtermos essa lista. Para isso, altere o comando para “GET“, apague o conteúdo do “Request Body” (uma vez que requisições GET não têm corpo) e configure o “Content-Type” para “application/json” ou “application/xml“, dependendo do formato que você quiser que seja retornado (se você não especificar um “Content-Type“, a Web API retornará JSON por padrão). Você pode ver o resultado dos requests dando um duplo clique na lista à esquerda:

Outra opção suportada nativamente pela Web API é a execução do comando GET para retornarmos um elemento em específico (passando o ID). Ou seja, se fizermos um request com o comando GET passando o endereço com final “/api/pessoa/1“, a Web API retornará a pessoa que tem ID “1“:

Executando um PUT

O comando PUT serve para enviarmos informações atualizadas sobre um determinado elemento. No nosso exemplo, podemos passar uma pessoa para esse comando e, baseando no “ID“, faremos a atualização do “Nome” e “Sobrenome“. Note que você tem que passar o ID da pessoa no endereço da requisição, caso contrário você receberá um erro (“Method not allowed“):

Executando um DELETE

Finalmente, o comando DELETE serve, obviamente, para deletar um registro. Da mesma maneira que o PUT, temos que passar o ID da pessoa que queremos deletar:

E com isso abordamos todos os comandos tipicamente implementados em Web APIs RESTful.

Concluindo

A interface do Fiddler parece muito intimidadora à primeira vista. Porém, uma vez que aprendemos pelo menos o básico dos seus elementos, fica bem fácil de utilizá-lo. Nesse artigo você aprendeu a configurar o Fiddler para fazer o debugging de Web APIs, bem como as principais tabs e controles utilizados para executarmos os quatro comandos REST.

Agora que você já sabe o básico do Fiddler, baixe-o agora mesmo e leve a experiência de debugar Web APIs para o próximo nível. Aproveite e deixe um comentário falando o que você achou dessa experiência.

Você já utilizava o Fiddler para debugar Web API? Não tem problema! Deixe um comentário também explicando para gente quais são as suas funcionalidades favoritas dessa ferramenta. Lembre-se: eu não sou um expert em desenvolvimento web e também estou curioso para saber mais sobre o Fiddler!

Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se aqui ou utilizando o formulário logo abaixo.

Até a próxima!

André Lima

Qual a diferença entre EnumerateFiles e GetFiles? Periscope replay: As 3 principais APIs que você pode implementar no seu app