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 é muito importante, pois define o design correto que utilizaremos para construí-la.
A versão 2.0 trouxe ainda um suporte mais aprimorado ao protocolo OData, que será abordado com mais detalhes a seguir, e com isso nos possibilita publicar serviços de dados padronizados, fazendo com que outros sistemas interoperem através de um protocolo aberto e simples de ser implementado.
O protocolo OData
Convivemos diariamente com uma vasta quantidade de dados, sendo que a cada intervalo de tempo mais e mais são criados. Estes dados só possuem importância se nos é possível acessá-los por aplicativos que utilizamos para algum fim, e aí que entra em cena o Open Data Protocol, usualmente chamado apenas de OData.
Este artigo busca apresentar de maneira introdutória este padrão que nos permite amplo acesso aos dados, descrevendo o que é e como surgiu, sua aplicação, o porquê da sua importância e como você pode utilizá-lo no seu cotidiano.
Um dos objetivos principais da utilização do protocolo OData é criar uma padronização na forma como os dados são acessados e manipulados através da rede. Essa padronização é necessária porque atualmente convivemos com diversas aplicações que expõem dados de diferentes maneiras, e muitas não utilizam um protocolo padrão, o que dificulta a interoperabilidade entre sistemas.
Eis que surge a questão: como este variado leque de clientes acessam estas diversas fontes de dados?
Uma alternativa seria cada fonte geradora de dados ter sua própria forma de expor os dados. Em contrapartida, isto exige que cada cliente contenha um código único para cada fonte de dados que irá acessar. Uma complicação para quem cria o código consumidor destes serviços.
Não menos importante, haveria também a necessidade de que os criadores de cada fonte de dados especificassem e implementassem sua própria abordagem para a obtenção destes dados. É como se cada criador tivesse que reinventar sua própria versão da roda toda vez que quisesse expor dados.
Com esta gama variada de soluções customizadas que teríamos em ambos os lados, seria praticamente impossível desenvolver um conjunto de ferramentas eficaz a ponto de facilitar a vida das pessoas.
Ao pensarmos mais um pouco, veremos porque esta opção, definitivamente, não é a melhor solução. Suponhamos que um aplicativo Web deseja expor seus dados em smartphones. Não havendo uma maneira comum para este processo, o aplicativo Web deve implementar a sua própria abordagem, obrigando todos os clientes desenvolvedores de aplicativos que precisam destes dados a suportar este formato próprio.
A escolha de uma abordagem comum a todas as ferramentas faz muito mais sentido. Através desta definição, simplesmente será necessário estabelecer uma maneira de modelar estes dados e um protocolo de acesso, criando flexibilidade nas implementações que consomem estes dados.
Considerando o cenário conectado em que vivemos, faz mais sentido construir a forma de acesso seguindo os padr ...
