Introdução a Asp.Net WebAPI    

No período de inatividade do Blog, muitas coisas aconteceram no Asp.Net, inclusive uma nova versão foi lançada com muitas melhorias. O Diagrama que mostrei neste post já está desatualizado e vou tentar correr atrás do tempo perdido para falar de alguns temas por aqui.

Introdução

O Asp.Net já está bastante consolidado com uma arquitetura sólida e extensível, permitindo o desenvolvimento seguindo diversos padrões e paradigmas. Como mencionado no post citado, sobre o Asp.Net existem varias outras camadas que possibilitam diferentes abordagens para desenvolver diferentes tipos de projetos, sendo que todas elas são válidas de acordo com o objetivo da aplicação. De forma rápida podemos citar algumas destas formas de desenvolvimento que o Asp.Net fornece: Web Forms, Asp.Net MVC, Dynamic Data, Web Pages e agora também o Asp.Net WebAPI. É exatamente sobre essa última forma que falaremos ao longo desse post . Farei aqui apenas de uma introdução teórica, e nos próximos posts mostrarei alguns exemplos.

É comum, quando ouvimos falar de tecnologias Web, pensarmos em sites ou sistemas que rodem em Browser, porém, Web é muito mais que isso. Arquiteturas de Nuvem, como o Azure da Microsoft ou o AWS da Amazon são bons exemplos de cenários onde hospedamos serviços na Web, com o objetivo de serem consumidos de qualquer origem, e não apenas de sites. Esse tipo de arquitetura orientada a serviço (SOA na sigla em inglês) além de fornecer um grande ganho em escalabilidade, sazonalidade, especialização, entre outros benefícios, pode ser consumido por muitos tipos de aplicações, como Windows, Cobol, Console ou qualquer outra tecnologia que não rode em Browser e necessite de dados centralizados e serviços dedicados.

Um bom exemplo de aplicação que consome serviços na Web em grande escala, e que é muito popular nos dias de hoje, são os aplicativos para SmartPhone. A grande maioria desses aplicativos está sempre conectada, consumindo serviços e exibindo-os para o usuário como se eles fossem locais.

Imagine agora você ter uma ótima ferramenta para prover serviços para toda essa gama de aplicativos, seguindo sempre uma mesma arquitetura e o mesmo padrão. Foi pensando nisso que a Microsoft criou o Asp.Net WebAPI, que nos dá todas as ferramentas e facilidades necessárias para conseguirmos alcançar todos esses objetivos

Como o próprio nome diz, WebAPI é forma que a equipe do Asp.Net nos dá para disponibilizar uma API (Application programming interface) hospedada na Web, ou seja, abrir uma porta na sua aplicação para que outras aplicações e serviços possam interagir com ela por meio de serviços HTTP. Para quem é desenvolvedor Windows esse conceito é muito comum, pois muitas vezes dependemos de APIs do sistema operacional para desenvolver alguma funcionalidade mais avançada.

Entendendo Asp.Net WebAPI

O Asp.Net WebAPI, diferente de outras tecnologias Web da Microsoft, como o WebForms, Asp.Net MVC ou WebPage, não é construído diretamente sobre a plataforma Asp.Net, ele é, na realidade, uma abstração feita sobre o Asp.Net MVC 4. Isso quer dizer que além de você fazer uso de toda a tecnologia compartilhada pela base do Asp.Net, você terá em mãos também toda a tecnologia especializada e já consolidada do Asp.Net MVC. Na prática, um projeto Asp.Net WebAPI é um projeto Asp.Net MVC com itens/arquivos a mais. Ele contém toda a configuração padrão de um projeto MVC normal. Isso é muito proveito, uma vez que você poderá fazer um site e no mesmo projeto disponibilizar serviços padronizados.

Encontramos no Asp.Net WebAPI termos muito comuns de aplicativos Asp.Net MVC simples. Por exemplo, nossos métodos são expostos através de Controllers e são alcançados através de Rotas, as diferenças estão basicamente em classes bases, que são específicas para cada camada.

Os Controllers do WebAPI, por exemplo, herdam de ApiController ao invés de simplesmente Controller, que é o caso dos controllers de uma aplicação padrão MVC. Por sua vez, os controllers do WebAPI não retornarão Views como ActionResult, pois não é esperado que serviços retornem telas ou relatórios, mas apenas dados. As Rotas também têm diferenças: sua configuração se dá através do método routes.MapHttpRoute ao invés do routes.MapRoute, dessa forma permitindo que o mesmo aplicativo/site tenha rotas configuradas para o WebAPI e para Controllers MVC padrões.

É interessante saber também que com o WebAPI você não precisa ter uma infraestrutura Web disponível para sua aplicação, ou seja, você não precisa do IIS para disponibilizar seus serviços REST em um protocolo HTTP. Com poucas linhas de código você consegue expor serviços em um Console Application, ou outro tipo de aplicação .Net, fazendo o que é chamado de Self-Host WebAPI. Apenas baixando um pacote no NuGet você já tem tudo que precisa para criar serviços sem IIS, apenas com o .Net instalado.

O que são serviços REST?

Você deve ter reparado que comentei algumas vezes de serviço REST até agora no post. Isso porque o WebAPI foi criado principalmente para geração de serviços REST. Apesar de ter citado o termo algumas vezes, ainda não deixei claro o que seria esse tipo de serviço. Tentarei agora fazer uma breve explicação desse conceito de serviço, já muito utilizado por diversos desenvolvedores, mas que é sempre bom ser esclarecido.

Já ficou evidente que o principal ganho ao desenvolver projetos com Asp.Net WebAPI é a facilidade em desenvolver serviços REST (Representational State Transfer). Apesar desse não ser o único tipo de serviço web possível com WebAPI, nitidamente essa é o tipo de serviço recomendado pela Microsoft ao utilizar WebAPI, como veremos a seguir. Para desenvolver serviços RPC (Remote Procedure Call), por exemplo, os WebServices ASMX ou WCF já são bem aptos e fáceis, enquanto que, por outro lado, desenvolver serviços REST em ASMX ou WCF não é tão simples como com WebAPI.

Para quem não sabe, a grande diferença entre serviços REST e RPC é que enquanto em REST os serviços expõem seus dados como recursos em URI e os clientes interagem com esses dados através de verbos HTTP, em RPC os serviços expõem diferentes métodos organizados de forma aleatória em uma ou mais URIs.

Por exemplo, um serviço REST teria sempre a mesma URI no formato MeuEndereco/MeuDado e de acordo com o verbo HTTP (POST, GET, PUT, DELETE), a aplicação poderia responder as requisições do Cliente sobre o “MeuDado”. Ou seja, o cliente pode obter um registro através do verbo GET ou salvar o mesmo registro com o verbo Put ou Post.

Por outro lado, no RPC, se fosse implementado em ASMX, seria algo assim MeuEndereco/MeuServico/ObterDado, MeuEndereco/MeuServico/SalvarDado, MeuEndereco/MeuServico/OutroMetodo, etc. Perceba que o final do endereço é um Método, e não um recurso, como é o caso do REST.

Serviços REST são muito úteis para expor serviços com a função CRUD sobre um dado, pois os principais verbos HTTP servem exatamente como os principais comandos SQL (SELECT, INSERT, UPDATE e DELETE). Mas é importante ter em mente que serviços REST não estão restritos a apenas operações CRUD.

Quando criamos um serviço REST, respeitamos todas as formas de comunicação estabelecidas pelo protocolo HTTP. Visitando esse post você pode ter uma noção de como funciona o HTTP. Além disso, você pode encontrar todos os códigos de Status pré-definidos em diversos sites da Web. No .Net existe o enum HttpStatusCode, no namespace System.Net o nome e o código de todos esses Status.

Também precisamos ter em mente ao modelarmos serviços REST que eles devem ser planejados para não ter estados, como Sessions, e devido a isso, cada Requisição deve ter toda a informação necessária para que o servidor possa processar a mensagem. E para ser padrão, ele deve retornar dados compreendidos na maioria das linguagens, ou seja, ele deve retornar geralmente XML ou JSON. É muito comum, quando criamos serviços seguindo o padrão REST, chamá-los de RESTFul.

Em quais situações utilizar o WebAPI?

Não é difícil responder a pergunta “Em quais situações utilizar o WebAPI”. Por ser um framework de serviço, qualquer oportunidade de utilizar uma camada de serviço pode ser exposta via WebAPI. Eu já citei o uso em SmartPhones, que talvez seja o mais comum, mas podemos encontrar muitos outros lugares. Sites como o Twitter, por exemplo, disponibilizam uma API inteira para nossos softwares interagirem com seus serviços. Sites de notícias pode disponibilizar APIs que vão além da funcionalidade exposta por um RSS, por exemplo, possibilitando sistemas de terceiros ranquearem e comentarem notícias. Aplicativos de SmartTV também têm se popularizado e também são consumidores de APIs. A lista seria enorme se colocássemos todas as possibilidades.

O importante é saber o que o WebAPI oferece e dessa forma poderíamos visualizar oportunidades de aplicação de serviços feitos em WebAPI em ainda mais lugares.

Por exemplo, é possível expor serviços OData via WebAPI de forma tão simples quanto expor serviços RESTFul simples. Para alcançarmos tal objetivo, precisamos apenas retornar um interface IQueryable em nossos métodos, que a aplicação cliente teria condições de pesquisar, ordenar e filtrar os registros de forma automática.

Obs: OData (Open Data Protocol) é um protocolo Web para pesquisar e atualizar dados através de tecnologias conhecidas na Web. É uma forma, por exemplo, de expor tabelas um Banco de Dado direto no protocolo HTTP e permitir que as consulta sejam feitas diretamente via HTTP.

É isso pessoal, hoje apenas introduzi o Web API, nos próximos posts mostrarei alguns exemplos.

Até logo!

15. janeiro 2013 04:13 by Frederico B. Emídio | Comments (0) | Permalink
Comments are closed

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET