Artigo Java Magazine 48 - REST com Struts 2

Clique aqui para ler esse artigo em PDF.

REST com Struts 2

Crie serviços com a arquitetura que está mudando a face da web

Exponha informações de maneira simples e perca o medo dos serviços na web, utilizando a arquitetura Representational State Transfer e o framework Struts 2

Na era da Web 2.0 a integração entre aplicações se faz cada vez mais necessária. Vemos surgir rapidamente na internet sistemas que agrupam conteúdo e funcionalidades de fontes diferentes, criando um novo serviço – os chamados Mashups. Esse tipo de aplicação é em parte fruto do estilo de arquitetura orientado a serviços, SOA, na qual o desacoplamento e a eficiência da reutilização de código são máximos.

Nesse contexto, as aplicações devem estar preparadas para disponibilizar as informações de diferentes maneiras e formatos. Por exemplo, para uma requisição Ajax, a aplicação deve ser capaz de retornar a resposta no formato texto, XML ou JSON (JavaScript Object Notation). Já para uma requisição feita por uma aplicação desktop, talvez XML seja a opção mais conveniente. (A Edição 46 traz mais informações sobre a utilização de JSON com Ajax.)

Então nos deparamos com a necessidade de expor serviços de maneira fácil, sem muita codificação, e de prover informações em formatos adequados para integrações (HTML, XML, JSON etc.). Para tal, vamos utilizar a arquitetura REST e a infra-estrutura fornecida pelo Struts 2.

A arquitetura REST

REST é um acrônimo de Representational State Transfer (Transferência de Estado Representacional). É um termo utilizado para descrever um estilo arquitetural de sistemas acessíveis pela rede. Você pode ver mais detalhes no quadro “O que é REST”.

De forma simplificada, vamos considerar que uma aplicação segue o estilo REST se ela expõe suas funcionalidades – ou serviços – através de URLs bem definidas (representando recursos). Nesse tipo de aplicação, o resultado do acesso aos recursos se dá em um formato de fácil leitura, como por exemplo XML, sobre o protocolo HTTP simples. No resultado estão contidos os endereços de navegação para outros recursos pertinentes, na forma de hiperlinks. Aplicações REST podem ser utilizadas como alternativas mais simples aos web services tradicionais baseados em SOAP.

A aplicação de exemplo

Para desenvolver o exemplo, usamos o IDE Eclipse com o Web Tools Project (mas você pode usar seu IDE preferido, sendo necessárias poucas adaptações). Para testar a aplicação usamos o Apache Tomcat. Todos os arquivos do exemplo estão disponíveis no site da Java Magazine.

Construiremos uma aplicação (chamada “WSStruts2”) com apenas duas entidades: Aluno e Disciplina. Funcionalidades que operam sobre essas entidades serão expostas como serviços e acessadas através de URLs simples. O retorno desses serviços poderá ser em XML ou em JSON.

Como vimos, a abordagem de definir recursos através de URLs faz parte da arquitetura REST, segundo a qual todo serviço exposto deve ser endereçado por uma URL única. No exemplo, os dois serviços que vamos expor serão a listagem dos alunos e o detalhamento de um aluno específico. Suas URLs são respectivamente:

§http://localhost:8080/WSStruts2/alunos

§http://localhost:8080/WSStruts2/alunos/xxx

Na segunda URL, xxx representa o código de um aluno em particular (ex.: 102). Observe que não há parâmetros para definir qual o serviço que desejamos. Isto é feito para que fique claro o propósito da URL. Esse é outro detalhe da arquitetura REST: minimizar o uso de parâmetros na definição dos recursos (pois eles inibem o “aprofundamento” das URLs). Exemplificando, considere as seguintes URLs:

http://localhost:8080/WSStruts2/AlunosAction.action?id=102

http://localhost:8080/WSStruts2/alunos/102

No primeiro exemplo, o uso do id do aluno como parâmetro dificulta a adição de novos serviços baseados no aluno especificado. Já no segundo podemos definir um novo serviço “aprofundando” a URL, como por exemplo:

http://localhost:8080/WSStruts2/alunos/102/disciplinas

É claro que o fato dos recursos receberem parâmetros (como no primeiro exemplo) não torna impossível adicionar o serviço de listar as disciplinas do aluno 102. Seria possível fazê-lo passando um novo parâmetro como em:

http://localhost:8080/WSStruts2/
   AlunosAction.action?id=102&propriedade=disciplinas

Mas o endereço anterior (.../alunos/102/disciplinas) é mais legível e auto-explicativo. Outro argumento para preferir o padrão sem parâmetros é que listar disciplinas de um aluno e mostrar detalhes são dois serviços diferentes e, portanto, deveriam estar em URLs diferentes.

Na arquitetura REST, os parâmetros são utilizados preferencialmente apenas para definir o formato das informações retornadas. Por exemplo, quando acessamos um serviço podemos querer o retorno em XML ou talvez em texto.

Em nosso exemplo, usaremos um parâmetro chamado tipoRetorno. A URL para exibir a lista de alunos no formato JSON ficaria então:

http://localhost:8080/WSStruts2/alunos?tipoRetorno=json.

Caso não seja informado o tipo do retorno, retornaremos XML.

Como usaremos o Struts 2

O Struts 2 já provê a infra-estrutura necessária para se trabalhar com a arquitetura REST e com diferente tipos de resultados. Criaremos duas configurações de Action, uma para a listagem de alunos e outra para o detalhamento de um aluno. Em ambas as Actions o resultado poderá ser expresso em formato XML ou em JSON. Quando a Action finalizar a execução, o Struts 2 fará a sua interpretação e retornará o formato indicado como parâmetro. A transformação de Java para XML ou para JSON será feita de maneira transparente.

Preparando a infra-estrutura

Para iniciar a construção do exemplo, abra o Eclipse e crie uma nova aplicação web (" [...] continue lendo...