ASP.NET Web API - Base Architecture

Services

0009A WebAPI é uma plataforma ideal para a construção de serviços baseados em HTTP, onde o pedido e a resposta acontecem no protocolo HTTP. Sendo assim o cliente pode fazer uma requisição GET, PUT, POST e DELETE obtendo a resposta adequadamente. Nos posts anteriores fiz um resumo sobre o WebAPI, onde codificamos e consumimos um serviço HTTP. Neste post, vamos analisar a arquitetura de processamento, trazendo alguns detalhes sobre o que acontece entre a recepção de um pedido HTTP e o retorno da resposta.

A arquitetura WebAPI é composta de três camadas: hosting, message handler pipeline, controller handling. Como pode ser visto na imagem abaixo:

ProcessingModel

Antes de falar sobre estas camadas, precisamos consolidar alguns conceitos base do WebAPI:

 

Route

A configuração de roteamento no WebAPI é ligeiramente diferente do roteamento do ASP.NET MVC. Enquanto temos as classes Routee RouteCollectionno ASP.NET MVC, no WebAPI iremos trabalhar com Route e HttpRouteCollection.Mesmo o time do WebAPI tendo utilizado a mesma lógica de routing do MVC, estes se diferem na estrutura. A ideia é tornar o Roteamento independente das classes ASP.NET, afim de ampliar sua capacidade de hospedagem.

Para determinar qual a ação deve ser invocada, existe uma tabela de roteamento. Logo abaixo temos o caminho predefinido, que está configurado no arquivo Global.asax da sua aplicação WebAPI.

04 rout

Untitled

Neste momento o framework do WebAPI recebe a solicitação HTTP e tenta encontrar a URI correspondente dentro do modelo de rotas na tabela de roteamento. Caso não seja encontrado, o retorno será um erro 404. A figura abaixo representa o fluxo

Routing WebAPI copy

Para tipos simples, o WebAPI utiliza apenas os dados da rota e os parâmetros de consulta a partir da URI requisitada. Já para tipos complexos, é necessário trabalhar com MediaTypeFormatters que são usados para serializar o corpo da solicitação com base no tipo de conteúdo (JSON, XML, etc).

 

Content Negotiation

O content negotiation no WebAPI, representa o processo de selecionar a melhor representação para uma determinada resposta. A engine do WebAPI implementa um tipo de negociação de conteúdos, o que permite ao cliente solicitar dados para um tipo específico de mídia.

Sendo assim, este é um mecanismo que permite ao servidor web devolver conteúdo em formato diferente usando a mesmo URL. A imagem abaixo explica este processo:

02 Content Negotiatio

Por padrão o WebAPI retorna os dados em formato JSON, mas graças ao content negotiation é possível solicitar um recurso especificando a mídia de retorno. Não vou aprofundar neste item pois já tenho um post específico sobre ele no forno.

 

Implementation   

Para uma implementação genérica do WebAPI, precisamos criar uma classe que deriva de ApiController. Ele é o responsável por fazer a mágica. Se na sua classe você tem um método prefixado ou decorado com GET, isso significa que você está tentando retornar dados com base em uma requisição. Sendo assim, você tem apenas que se certificar que todos os método codificados estão prefixados ou decorados com o tipo de solicitação desejada (GET, POST, PUT, DELETE).

089898

Isto significa dizer que não estamos dependentes de utilizar única e exclusivamente a interface WebAPI dos templates WEB do Visual Studio. Podemos criar um serviço WebAPI partindo de uma console aplication, e isso é possível graças a camada de Hospedagem que será o nosso próximo passo.

 

Hosting

A primeira camada ou camada inferior desta arquitetura é a hospedagem. Esta camada atua como uma interface entre a WebAPI e uma infra-estrutura subjacente para o HTTP como o próprio ASP.NET clássico. Em resumo esta camada cria o HttpRequestMessage enviando para o manipulador da camada superior. É também na camada de hospedagem que temos o processamento do HttpResponseMessage antes de ser devolvido ao handler pipeline.

Lembre-se que HttpRequestMessage e HttpResponseMessage são classes novas para representar mensagens HTTP, introduzidas na versão 4.5 do Framework.

Hoje, as opções de hospedagem são: self-hosting, web-hosting e cloud-hosting.

Self-Hosting

Sef-hosting ou Auto-Hosting é a opção de hospedar APIs em um processo que não seja o IIS. Sendo assim, podemos utilizar por exemplo um Console Application ou um Windows Service como hospedagem do serviço. Isto é possível por que este tipo de hospedagem é baseada no ASP.NET clássico.

Web-Hosting

Nesta opção é utilizado o IIS para hospedar APIs Web, o que nos dá traz uma série de recursos para a gestão dessas APIs, como controle de acesso, segurança, reciclagem de processo e outros. Neste modelo de hospedagem reutiliza a infraestrutura do ASP.NET ou ASP.NET MVC para executar os serviços. O web-hosting é baseado em IHttpAsyncHandler que chama HttpControllerHandler que converte uma HttpRequest em HttpRequestMessage.

É neste caso que utilizamos o template Web disponível no Visual Studio para construir nossos serviços. Exatamente como no exemplo do post: ASP.NET Web API – Criando e consumindo dados [Parte 1]

Cloud-Hosting

Utiliza o Windows Azure para publicar e rodar as APIs. O principal atrativo desta opção é a facilidade em escalonar sem a necessidade de mudanças na API, já que a responsabilidade fica por conta dos mecanismos de gestão e execução do Windows Azure que são capazes de identificar a necessidade de adicionar novas instâncias ao load balance a fim de atender a demanda solicitada.

Outros

O WebAPI não se limita a estas opções. Há já alguns hosts adicionais, contribuídos pela comunidade:

Para uma melhor compreenção, segue um exemplo de self-hosting do WebAPI:

03

No exemplo acima, a aplicação escuta em uma URL específica, no caso a localhost 8080. Para executar este código é necessário ter privilégios de administrador. Caso ocorra o erro: “HTTP could not register URL”, basta executar o comando abaixo no command prompt executando como Adminstrador.

01 cmd

Como pode ser visto, estamos utilizando um projeto console para hospedar nosso serviço, mas neste tipo de hopedagem poderia ser qualquer outro processo do .NET.

 

Message handler pipeline

O manipulador de mensagem é a classe que recebe a requisição HTTP e retorna a resposta da requisição. Os manipuladores são classes que herdam da classe abstrata HttpMessageHandler.

Esta camada da arquitetura é composta por um manipulador de mensagens semelhante ao que existe no WCF. Esta pipeline é exposta pela classe HttpServer. O manipulador de mensagem é simplesmente uma abstração para uma operação que recebe uma mensagem de requisição HTTP (HttpRequestMessage) e retorna uma mensagem de resposta HTTP (HttpResponseMessage).

656565

Esta organização do pipeline proporciona uma grande flexibilidade no tipo de operações que podem ser realizadas, mas em suma, a requisição é enviada, tratada pelo DelegatingHandler que é o cara responsável por manter uma referência para o manipulador interno. Após isso já com o método da URI definido, o manipulador guarda o código de status da resposta para ser devolvido a camada de cima.

 

Controller Handling

A camada superior da arquitetura do WebAPI, corresponde ao processamento do controller a saber:

    • Action selection – Realiza a seleção das ações baseado em reflexão;
    • Filter execution – Define os métodos a serem utilizados para os filtros das ações;
    • Model binding – Define os métodos necessários para a ligação com o modelo;
    • Action invocation – Invoca os métodos para a ação de um controlodor;
    • Response content creation via formatters – Classe base para trabalhar com a serialização e desserilalização tipados usando ObjectContent.

Todo o processo ocorre dentro do ApiController e é chamado pela HttpControllerDispatcher. Sua função nesta brincadeira é selecionar, criar e chamar o controlador correto para realizar a requisição.

 

Conclusão

A ideia deste post é trazer mais uma luz sobre a motivação por trás da criação do ASP.NET Web API fazendo uma análise do seu modelo base de programação atravéz de sua arquitetura.

 

Até mais e bom estudo a todos!

Me Azul

Twitter: @vitormeriat

vitormeriat@gmail.com

vitor.pereira@studentpartner.com


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


8 minutes to read