Artigo .net magazine 70 - Crie um Microblog estilo Twitter - Parte 3

Crie um Microblog estilo Twitter

Criando um “DevTwit”, com AJAX e REST – Parte 3

Na primeira parte deste artigo começamos com uma análise de alguns cenários típicos de projeto. Iniciamos a parte prática com a criação do layout em um editor de imagem, tranformamos o layout em HTML e validamos sua construção no W3C. Por fim, criamos a base da nossa plataforma AJAX.

Na segunda etapa criamos a base de dados, as entidades e classes utilizando o Entity Framework, cuja principal função é criar entidades conceituais (Entity Data Model) a partir de uma fonte de dados. Criamos a base de dados, a camada de autenticação (Figura 1), classes do repositório e integração com as telas (Figura 2 e Figura 3). Vimos também um pouco de LINQ e seus princípios.

Nesta terceira e última etapa do artigo vamos escrever um serviço web com autenticação personalizada, baseado nos princípios REST. Para o serviço vamos utilizar o ADO.NET Data Services (codinome Astória). Usando o REST, vamos simular a criação de uma API para o nosso DevTwit, tornando-o aberto para integração com sistemas de terceiros (como faz o Twitter). Faremos, inclusive, uma aplicação externa ao DevTwit que usará sua própria API.

Antes de aplicarmos as técnicas ao DevTwit, vamos examinar alguns fundamentos da arquitetura e tecnologias envolvidas, como IHttpModule (que será usado na parte se segurança), Web Services, RPC, REST, ADO.NET Data Services, detalhes sobre a segurança no REST e mais. Todos esses fundamentos são essencias e importantes para um perfeito entendimento da parte prática deste artigo.

 Web Services

Web services são uma maneira simples de integrar sistemas, utilizando como base um arquivo texto, estruturado, capaz de ser lido por praticamente qualquer plataforma. Hoje, temos inúmeros exemplos de sistemas que trabalham com Web Services. Desde uma loja virtual, que deseja capilarizar suas vendas, permitindo que outros web sites façam revendas, utilizando o seu mecanismo de pagamento e regras de negócios. Sistemas voltados à medicina e pesquisas também utilizam bastante esta tecnologia. Temos até serviços de informação, como busca de endereço através do CEP, consulta ao SERASA, cotações etc. Existem inúmeras formas de integrar sistemas através da web utilizando serviços, que podem ser tanto simples como mais complexos, dependendo da tecnologia aplicada.

RPC (Remote Procedure Call) significa chamada de procedimento remoto, utilizado para criação de aplicativos cliente/servidor. O RPC é um estilo (sendo o SOAP o protocolo mais utilizado) para criação de aplicativos cliente/servidor. O serviço permite que métodos (funções ou procedimentos) sejam invocados de outra máquina, como se estivessem trabalhando localmente. Isto permite criar serviços web focados nas operações, como carregarCliente(), adicionarCompra(), excluirRevista(), entre outros.

Qualquer plataforma que forneça uma comunicação HTTP e consiga trabalhar com arquivos XML pode implementar o SOAP de forma simples, dando uma grande vantagem de independência de plataforma.  Por usar prioritariamente o transporte HTTP ele consegue ser transportado sem requisitar nenhuma configuração especial em redes e firewall. Em suma, se houver acesso à internet disponível, o web service poderá ser acessado. O web service pode ser projetado para trabalhar com diversos servidores (web farms), possibilitando assim um ganho de escalabilidade nunca antes visto.    

REST

REST significa Representational State Transfer. É um conjunto de diretrizes de desenvolvimento de software para distribuição de sistemas hipermídia distribuídos que trabalham em cima do HTTP. O termo se originou no ano de 2000 em uma tese de doutorado de Roy Fielding, um dos principais autores da especificação do protocolo HTTP. O REST baseia-se nas requisições HTTP (POST, PUT, GET e DELETE).

Estes dados podem ser representados por JSON ou XML, definidos através do content-type. O content-type do HTTP define o tipo do conteúdo da resposta, como por exemplo, HTML, JPEG, XML, entre outros.

Quando os protocolos de comunicação foram surgindo, como exemplo, CORBA e SOAP, um movimento contra estes protocolos surgiu, alegando que eles não entendiam os princípios básicos de comunicação via Internet. O HTTP havia sido projetado para atender todas as necessidades que o CORBA, SOAP e outros procuravam suprir. O REST, por se basear em comunicação voltada a HTTP, é facilmente integrado com outros sistemas independente da plataforma.

Deixando estes “conflitos” de lado, a ideia geral do REST é que ele seja um espelho do design da aplicação, onde cada recurso possui uma URL única e de fácil compreensão para as pessoas. As URLs devem possibilitar descobrimentos de novos recursos, como exemplo, se uma url "www.seusistema.com.br/clientes" trouxer uma lista de clientes, "www.seusistema.com.br/clientes/cliente01/compras" intuitivamente traz a lista de compras do cliente 01. É lógico que, baseado no endereço do cliente 01, seu eu quiser saber a compra do cliente 02, o endereço seria "www.seusistema.com.br/clientes/cliente02/compras".

De acordo com os princípios REST as URLs devem, por si só, trazer todas as informações necessárias da requisição, ou seja, não pode haver informações salvas no cliente e no servidor que mantenha o estado. Em suma, não é permitida a utilização de cookies ou sessão para manter o estado da requisição. Um usuário deve poder enviar o endereço para outra pessoa, que visualizará as mesmas informações. Logicamente que as questões de autenticação e privacidade da informação devem ser levadas em conta. Mais adiante veremos como tratar a questão da segurança.

Cada recurso deve ter uma identificação única e, no caso da web, o recurso é uma URL. As URLs devem permitir uma fácil navegação pelo usuário, seguindo a lógica do seu endereço. Estes recursos são "