Serviços HTTP com suporte a OData

Ao longo dos anos a necessidade de desenvolver aplicações e serviços que sejam interoperáveis e se encontrem disponíveis para a maioria dos dispositivos tem se tornado um desafio no dia a dia de desenvolvedores das mais diversas tecnologias. Isso devido ao grande público que os smartphones, tablets, e outros dispositivos móveis vêm conquistando.

A fim de suprir a demanda pela alta necessidade em manter os sistemas conectados, sejam móveis ou não, acabamos nos lançando atrás de encontrar a melhor maneira e a melhor tecnologia para utilizar nestes cenários. E durante esse processo de busca, acabamos muitas vezes nos deparando com terminologias como Representational State Transfer ou simplesmente REST, JavaScript Object Notation (JSON), entre outras. Mas como utilizá-los na prática e da melhor maneira possível?

Atualmente na plataforma Microsoft .NET a tecnologia recomendada e mais atual para criar aplicações RESTful é o ASP.NET Web API. Ele disponibiliza um conjunto de classes e abstrações para facilitar a forma de interagir com o protocolo HTTP habilitando o desenvolvedor a criar serviços sob este protocolo e no estilo arquitetural REST.

No decorrer do artigo vamos esclarecer alguns conceitos sobre REST e boas práticas no desenvolvimento com Web API.

O protocolo HTTP não foi criado somente para servir páginas e web sites, mas através da sua especificação que contempla métodos HTTP, formas de negociação de conteúdo, regras de codificação e formas de transporte de dados, para criar mecanismos, ou serviços, que sejam acessados facilmente através da rede das mais variadas plataformas, pois hoje em dia, a maioria das tecnologias possuem recursos embutidos para realizar chamadas HTTP.

ASP.NET Web API 2

Com o lançamento da versão 2.0 do ASP.NET Web API, diversas melhorias e novos recursos foram incorporados nesta release, como por exemplo:

· Mapeamento de rotas através de atributos;

· Suporte a OAuth 2.0;

· Melhorias no suporte a OData;

· Envio de requisições em pacotes;

· Suporte a Portable API;

· Suporte a Cross Origin Resource Sharing;

· Integração com Open Web Interface;

· Novos tipos de contextos e resultados.

Se você já está familiarizado com ASP.NET MVC não sentirá muitas dificuldades em começar a desenvolver com ASP.NET Web API, pois a maneira de criar as classes de controle são bem parecidas. A grande diferença entre as classes de controle do ASP.NET MVC e do ASP.NET Web API é conceitual, ou seja, enquanto as ações do ASP.NET MVC são acessadas utilizando o nome, o ASP.NET Web API faz uso dos verbos HTTP para encontrar a ação correta.

A forma recomendada de acessar as ações do serviço criado é utilizar o verbo desejado que seja informado no cabeçalho da requisição HTTP.

O verbo, ou também “Método HTTP”, é peça fundamental para a correta construção de serviços HTTP que utilizam REST como estilo de arquitetura escolhido. Muitas vezes isso é esquecido ou mesmo negligenciado, fazendo com que um serviço seja acessado da mesma maneira que uma tela ASP.NET MVC, pelo seu nome.

Os tipos de retorno que são informados na ação, como correspondente ao verbo, deverão ser o mais genérico possível, a fim de facilitar a construção e utilização de diferentes tipos de dados no decorrer do desenvolvimento. Utilizar a interface IHttpActionResult é uma boa maneira de atingir esse objetivo.

Um serviço criado no Web API pode ser acessado pelos mais variados dispositivos, desde smartphones, tablets, browsers, entre outros. Isso se deve à forma simples e objetiva de acessar o serviço aonde quer que ele esteja hospedado.

Inclusive o Web API fornece suporte aos mais variados tipos de hospedagem, seja no Internet Information Services (IIS), Windows Azure, utilizando OWIN ou até mesmo Self-Hosted em alguma camada de aplicativo.

Um detalhe que devemos observar quando criamos serviços seguindo o conceito de APIs expostas na Web, é quanto a sua intenção, ou seja, uma API na Web deve ser designada para prover funcionalidades para outros sistemas, e não para ser acessada diretamente pelo navegador do usuário. Isso é ...