Há algum tempo a comunidade criou uma especificação chamada OWIN (Open Web Interface for .NET), que convencionou uma camada de abstração entre os servidores web (por exemplo, o IIS) e os frameworks para desenvolvimento de aplicações Web, desacoplando um do outro e assim facilitando a portabilidade de aplicações entre os mais diversos modelos de servidores web e/ou sistemas operacionais, bem como a fácil criação e integração de novos componentes que não devem ser dependentes do servidor web onde eles estão sendo executados.

Com este modelo já bem difundido, a Microsoft criou um projeto chamado Katana, que nada mais é que uma implementação desta especificação. Até pouco tempo atrás, os projetos ASP.NET dependiam da biblioteca System.Web.dll (parte do .NET Framework), e que esta possuia forte dependência do IIS, fazendo com que as aplicações ASP.NET serem, obrigatoriamente, hospedadas lá. Aos poucos, os projetos ASP.NET (MVC, Web API, SignalR, etc.) foram se “livrando” da dependência desta DLL, possibilitando assim que estes projetos sejam construídos e levados para serem executados em qualquer ambiente.

Para fazer uso do OWIN em conjunto com o ASP.NET Web API é bem simples graças a sua estrutura enxuta e simplista, que combinado com algumas estensões (do C#), resume a configuração em poucas linhas de código e, consequentemente, já torna a aplicação independente do hosting onde ela está sendo executada. O primeiro passo para criar uma aplicação console (self-hosting) capaz de hospedar uma Web API é instalar o pacote, via Nuget, chamado Microsoft.AspNet.WebApi.OwinSelfHost. Ao instalar, várias DLLs são baixadas e podemos visualizar isso através das referências que foram realizadas no projeto.

O ponto de entrada para a configuração é a criação de uma classe com um método público chamado Configuration, que recebe como parâmetro um objeto que implemente a interface IAppBuilder (OWIN), e via Reflection, ele será acessado pelo runtime. É no interior deste método que faremos a configuração necessária para que as APIs Web funcionem, e como sabemos, toda a configuração para o ASP.NET Web API é concentrada na classe HttpConfiguration. Depois de devidamente configurado, devemos recorrer ao método Use[XXX], exposto através da interface IAppBuilder, que adiciona um componente (conhecido como middleware) no pipeline para execução.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();

        config.Routes.MapHttpRoute(“Default”, “{controller}”);

        app.UseWebApi(config);
    }
}

Depois da classe de configuração criada, temos que recorrer à classe estática WebApp que através do método Start, recebe como parâmetro genérico o tipo da classe que servirá como responsável pela configuração e pelo pipeline de execução, e também temos que informar a URL em que a Web API ficará disponível/acessível.

using (WebApp.Start<Startup>(“http://localhost:8080&#8221;))
{
    Console.WriteLine(“Iniciado”);
    Console.ReadLine();
}

E como vimos na imagem acima, dentro deste projeto também temos uma classe chamada ClientesController (que herda de ApiController) que contém os métodos que recebem e retornam clientes, e quando acessado por alguma aplicação, o resultado é devolvido conforme esperamos, sem qualquer diferença quando comparado à hospedagem no IIS.