Turbinando aplicações Java com REST e Backbone.js

Pare e reflita: com tantos frameworks Java para facilitar o ciclo de vida de aplicações web, falar sobre aplicações inteligentes no client-side não seria andar na contramão? Além disso, o que seria uma aplicação inteligente no client-side e como é sua arquitetura?

Este autor que vos escreve publicou o artigo “O que preciso saber sobre HTML 5?” na Edição 116 da Java Magazine, apresentando o HTML 5 como uma alternativa ao desenvolvimento baseado exclusivamente no server-side. Esta tecnologia introduz e padroniza diversas funcionalidades inovadoras no navegador ou dispositivo móvel cliente, de forma segura, portável e nativa.

Tal artigo apresentou ainda dois pares de conceitos que não são sinônimos, apesar de serem confundidos muito frequentemente: front-end e back-end versus client-side e ­server-side. Veja a seguir:

· Front-end e back-end descrevem o tipo da ação a ser realizada:

o Front-end é a parte da aplicação que interage com o usuário;

o Back-end é a parte da aplicação que contém lógica de negócio e acesso aos dados, geralmente expostos como serviços;

o Observação: um front-end pode comunicar-se com múltiplos back-ends. Já um back-end pode servir a múltiplos front-ends e também a outros back-ends.

· Client-side e server-side descrevem onde a ação é realizada:

o Client-side é o lado da aplicação que roda dentro do navegador ou dispositivo do usuário;

o Server-side é o lado da aplicação que roda em um servidor;

o Assim como o caso acima, um client-side pode comunicar-se com múltiplos server-sides. Já um server-side pode servir a múltiplos client-sides e também a outros server-sides.

Observamos que, historicamente, aplicações web feitas em Java executam o front-end no client-side e o back-end no server-side. Simples assim. Neste artigo, apresenta-se uma alternativa onde tanto o front-end quanto parte do back-end são executados no client-side, com a alcunha de aplicação inteligente no client-side. Neste tipo de aplicação, o back-end do client-side também se comunica com um segundo back-end, agora no server-side.

Trazer a experiência desktop para aplicações web significa reduzir o tempo de resposta e de navegação. Além disso, uma aplicação inteligente no client-side trabalha sem depender de plug-ins, através de uma única base de código-fonte client-side independente de dispositivo e plataforma, ou seja, que pode funcionar tanto em computadores quanto em dispositivos móveis.

Ainda, convém pensar que aplicações web, mesmo sendo compostas por diversas camadas e componentes, representam um único conceito para o usuário final. Para ele, é muito mais interessante utilizar um produto que responda rapidamente aos seus estímulos e proporcione boa usabilidade, onde quer que ele esteja rodando.

Ok, posso já ter convencido alguém sobre investir no desenvolvimento de aplicações inteligentes no client-side. Mas como isto funciona na prática? Como seria sua arquitetura? E como esta solução difere-se dos frameworks que gerenciam o ciclo de vida web como o Struts? Confira a seguir.

Arquitetura de aplicações web no client-side

Aplicações web no client-side podem ser:

· Isoladas (dispensando o server-side), possuindo apenas o front-end. Exemplo: uma aplicação JavaScript que mostra a hora local nas principais capitais mundiais;

· Isoladas (dispensando o server-side), mas possuindo tanto front-end quanto back-end. Exemplo: uma aplicação JavaScript de controle de tarefas que armazene os dados no local storage do navegador;

· Integradas com o server-side, executando o front-end no client-side e o back-end no server-side. O client-side comunica-se com o server-side através de requisições HTTP, cujo formato da resposta é HTML, sendo assim diretamente processada pelo navegador. Exemplo: uma tradicional aplicação Struts de controle de entregas;

· Integradas com o server-side, mas agora executando tanto o front-end quanto uma parte do ­back-end no client-side, que se comunica com outro back-end no server-side. Aqui, o client-side também se comunica com o server-side através de requisições HTTP, mas o formato da resposta agora é JSON ou XML (pois transmitem apenas dados), sendo processada por um componente do client-side, que então gerará HTML e renderizará no navegador.

As aplicações inteligentes no client-side abordadas neste artigo seguem o quarto cenário apresentado, utilizando o estilo arquitetural REST e o formato de dados JSON.

Estilo arquitetural REST

Em uma visão bem simplificada, REST (ou REpresentational State Transfer) é um estilo arquitetural stateless para sistemas distribuídos, baseado no protocolo HTTP. Em REST, os métodos HTTP representam os verbos (ações), as URIs representam os substantivos (os destinatários das ações, ou recursos) e códigos de status HTTP representam a resposta das ações. Este artigo foca-se nas seguintes ações REST:

· HTTP POST: criar recurso. Ex: POST /users cria um usuário (passando seus dados no corpo da requisição);

· HTTP GET: ler recurso. Ex: GET /users/1 recupera o usuário com id = 1 ou ainda GET /users recupera um array com todos os usuários;

· HTTP PUT: alterar recurso. Ex: PUT /users/1 altera o usuário com id = 1 (passando seus dados no corpo da requisição);

· HTTP DELETE: remove ...