Artigos Java Construindo RESTful Web Services com JAX-RS 2.0
Por que eu devo ler este artigo:A versão 2.0 do JAX-RS adicionou uma porção de melhorias importantes que simplificam o desenvolvimento e permitem a criação de aplicações mais robustas e sofisticadas. Neste artigo, um exemplo prático é utilizado para demonstrar como construir, a partir do zero, uma aplicação completa (cliente e servidor) empregando tal tecnologia. O estudo realizado será útil em situações nas quais o leitor queira escrever aplicações para disponibilizar serviços baseados na arquitetura REST e, também, caso o mesmo necessite consumir tais tipos de recursos. O exemplo discutido mostra como o framework JAX-RS 2.0 pode ser aplicado em situações corriqueiras no desenvolvimento de software, tais como, na criação de cadastros básicos (os bem conhecidos CRUDs) e na publicação e consumo de arquivos binários (por exemplo, fotos, imagens, relatórios PDF e etc.).

RESTful Web Services são serviços que podem ser publicados na internet para que clientes espalhados ao redor do mundo possam ter acesso aos seus recursos disponibilizados. Estes serviços são construídos com base na arquitetura REST (Representational State Transfer ou, em português, Transferência de Estado Representativo), a qual fornece um estilo de aplicação cliente-servidor para a transferência de representações de recursos sobre o protocolo HTTP.

Nesta arquitetura, dados e funcionalidades são considerados recursos e são acessados via URIs (Uniform Resource Identifiers ou, em português, Identificador Uniforme de Recursos); os tão conhecidos links na web. Um recurso pode ser qualquer informação, como dados de uma pessoa, de uma tarefa ou mesmo um post em um blog. Por exemplo, podemos considerar a previsão do tempo de uma determinada cidade como um recurso.

Na internet, este tipo de informação é normalmente representado como uma página HTML, um arquivo de imagem ou mesmo um documento XML. Um cliente qualquer na web pode acessar este recurso e, dependendo do caso, pode solicitar a alteração ou a remoção do mesmo. Esta manipulação de informações é normalmente baseada nas operações GET, PUT, POST e DELETE do protocolo HTTP, onde PUT e POST são as operações que criam e alteram recursos, GET é a responsável por buscar as informações e DELETE por removê-las.

É importante destacar que na arquitetura REST os recursos são completamente desacoplados de sua representação, de forma que um mesmo recurso pode possuir diversas representações. Entre as mais utilizadas atualmente estão: JSON, XML, páginas HTML, documentos PDF e arquivos JPG.

Esta diversidade de representações de um mesmo recurso facilita a integração de diferentes tipos de clientes, como web browsers, smartphones, tablets, aplicativos desktop, entre outros.

Diferentemente dos web services tradicionais que trafegam envelopes SOAP (Simple Object Access Protocol ou, em português, Protocolo Simples de Acesso a Objetos) sobre qualquer protocolo de comunicação, RESTful Web Services foram desenhados para trafegar principalmente sobre o protocolo HTTP. A grande vantagem disto é que estes web services podem se beneficiar de padrões amplamente utilizados e consolidados na internet.

Dentre eles estão o suporte a cache de recursos, autenticação, segurança da informação, entre outros. Além disto, por possuir um conteúdo normalmente menor do que os tradicionais envelopes SOAP, estes web services são considerados “leves” (lightweight).

O tempo de transferência dos dados na rede e a quantidade de processamento necessário para empacotar/desempacotar as mensagens também é menor do que os baseados em SOAP. Ainda mais, como foi mencionado anteriormente, RESTful Web Services podem se beneficiar de várias funcionalidades já providas pelo protocolo HTTP, fazendo com que sua implementação seja mais simples e livre de complexidades desnecessárias.

O acesso de um cliente a um web service publicado na arquitetura REST também é mais simples do que o acesso aos web services tradicionais. Isto é, basta ter um browser ou a API básica de uma linguagem de programação e pronto. É só fazer a requisição HTTP e analisar a resposta.

Em contra partida, para acessar ou testar web services baseados em SOAP é necessário ter ferramentas e frameworks complexos, os quais devem atender a todas as normas da especificação de tal solução.

É importante destacar que REST é apenas um estilo arquitetural e não, como muitos pensam, um modelo formalmente definido. Por este motivo, não existe uma definição detalhada e padronizada de como a troca de mensagens entre cliente e servidor deve ocorrer. Isto varia de acordo com a interpretação de cada pessoa. Em outras palavras, cada empresa/desenvolvedor pode definir seus serviços com um estilo próprio.

Por este motivo, apesar de serem serviços mais “leves” que os baseados em SOAP, muitas empresas preferem continuar utilizando os web services tradicionais para obter o padrão e formalismo desejado.

No Java, o suporte para a implementação de RESTful Web Services foi adicionado em 2008 pela especificação JSR-311, a qual recebeu o nome JAX-RS. Esta especificação foi criada para simplificar o desenvolvimento de aplicações REST e, rapidamente, se tornou de extrema importância, pois foi um dos primeiros frameworks baseados em classes POJO e anotações capaz de publicar serviços RESTful.

Agora, cinco anos depois, o JAX-RS 2.0 foi lançado juntamente com a especificação Java EE 7. A nova versão, baseada na JSR-339, adicionou uma porção de melhorias importantes que simplificam ainda mais o desenvolvimento e permitem a criação de aplicações mais robustas e sofisticadas. São elas:

  • Suporte aprimorado a negociação de conteúdo. Negociação de conteúdo é o processo de seleção da melhor representação de uma resposta do servidor quando múltiplas opções são disponíveis. Com o intuito de permitir priorizar certas representações durante este processo, a anotação @Produces foi enriquecida com a adição do fator relativo de qualidade do servidor (o qs-value);
  • Criação de uma API para o cliente. A API do JAX-RS 1.0 era voltada estritamente para o lado do servidor, forçando o desenvolvedor a abrir conexões HTTP “na mão” ou utilizar alguma implementação de terceiros no lado do cliente. O JAX-RS 2.0, por sua vez, adicionou construtores (builders) para invocar um RESTful Web Service a partir do cliente. Esta nova API, além de simplificar o desenvolvimento, padroniza com uma forma elegante os acessos a este tipo de web service;
  • Adição de Filtros e Interceptadores. A nova API fornece a capacidade de encadear filtros de Servlets de acordo com o padrão Chain of Responsibility. Isso é útil para implementar funcionalidades ortogonais na aplicação, como o clássico logging e customizações de autenticação e autorização.

Os interceptadores são similares aos filtros, exceto pela capacidade de “embrulhar” (wrap) uma invocação de método em um ponto de extensão especificado. No JAX-RS 2.0 mais especificamente, os interceptadores são usados para manipular e enriquecer os dados do corpo de uma mensagem;

  • Suporte a especificação JSR 349: Bean Validation 1.1. O framework Bean Validation está integrado ao novo JAX-RS, agindo como facilitador para especificar metadados de validação de parâmetros. Por exemplo, a anotação @NotNull indica que o parâmetro anotado não pode ser nulo. É possível também utilizar outras anotações pré-definidas ou customizadas para garantir a “corretude” dos dados sendo manipulados;
  • Suporte a chamadas assíncronas. No JAX-RS 1.0 o cliente tinha que esperar o servidor responder suas requisições uma vez que a API não suportava chamadas assíncronas. Já, na versão 2.0, o suporte assíncrono foi introduzido para permitir que um cliente faça uma chamada RESTful e, opcionalmente, obtenha uma referência de Future para ser notificado quando a resposta estiver completa;
  • Quer ler esse conteúdo completo? Tenha acesso completo