Clique aqui para ler esse artigo em PDF.
JSR-311 e Jersey
Web services REST no Java EE
Apresentando a JSR que traz o suporte a serviços REST para Java EE, com alta produtividade e flexibilidade
De que se trata o artigo:
Apresentação da JAX-RS (Java API for RESTful Web Services) e do Jersey, sua implementação de referência. Estes são componentes utilizados no desenvolvimento de web services REST. A JAX-RS fará parte do Java EE 6.
Para que serve:
A JAX-RS busca simplificar o desenvolvimento de serviços REST e oferecer uma forma padrão de implementação desta linha de serviços. O Jersey implementa os recursos definidos pela JSR e acrescenta algumas funcionalidades, como o WADL (descritor de serviços REST) e uma API para clientes REST.
Em que situação o tema é útil:
Os web services REST são cada vez mais usados em integrações entre aplicações e empresas. Eles constituem uma forma de integração que nos traz muito poder e flexibilidade. A JAX-RS e o Jersey facilitam a integração com aplicações de diversas plataformas, utilizando formatos de dados variados. Isto aumenta a produtividade e elimina tarefas onerosas dos desenvolvedores.
JSR-311 e Jersey:
As duas linhas de desenvolvimento de web services são WS-* e REST. A JSR-311 e o Jersey trazem mais facilidade e produtividade ao desenvolvimento de serviços REST.
O uso destes componentes nos permite desenvolver web services com bastante poder e flexibilidade. Conseguimos suportar a manipulação de conteúdo
O objetivo da JSR-311 é oferecer uma API padrão para os serviços REST
Esta API fará parte do Java EE 6, o que facilitará ainda mais a interoperabilidade de serviços desenvolvidos com estes componentes. Web services já representaram a troca de performance por interoperabilidade. A JAX-RS e o Jersey nos ajudam a mostrar que isso ficou no passado.
Nas edições 54, 55 e 56 tivemos uma série de artigos sobre desenvolvimento de web services. Nesta série apresentamos as principais características das abordagens WS-* e REST. Para ajudar na contextualização por parte dos leitores, tivemos dois artigos práticos com propostas de soluções com WS-* e REST para um mesmo problema (serviços de um processo de leilão do Mercado Livre).
Na Edição 56 foi apresentada uma solução sem a introdução de muitos componentes que pudessem desviar o foco da essência do problema. O objetivo era mostrar as principais preocupações que os desenvolvedores devem ter ao modelar arquiteturas com REST. Indicamos que alguns componentes que agregam produtividade e qualidade às implementações seriam cobertos em artigos posteriores.
Falaremos agora sobre um destes componentes, a JSR-311 e o projeto Jersey, implementação de referência desta JSR. Falaremos inicialmente sobre a JSR em si, e depois mostraremos os principais pontos nos quais ganhamos ao utilizá-la.
JAX-RS: Java API for RESTful Web Services (JSR-311)
A versão 5 do Java EE fez um grande esforço para simplificar o desenvolvimento nesta plataforma. Esta iniciativa era muito desejada pelos desenvolvedores, e conseguiu renovar o ânimo dos profissionais que trabalham com a plataforma Java. Até o J2EE 1.4, a complexidade das aplicações vinha crescendo progressivamente. Muitos profissionais estavam debandando para alternativas como o Spring e o Hibernate, e alguns até mudando de plataforma (principalmente para Ruby on Rails).
No Java EE 5 o desenvolvimento de web services WS-* já foi bastante facilitado com a chegada do JAX-WS. Este componente traz mais produtividade ao permitir o desenvolvimento de serviços com anotações, substituindo uma grande quantidade de descritores.
Existe nesta área uma crescente adesão aos web services REST, conforme discutimos na série de artigos mencionada. Para oferecer melhor suporte a esta linha de serviços em Java, foi criada a JSR-311. O quadro “Objetivos da JSR-
Objetivos da JSR-311
A JSR-311 chegou para oferecer suporte aos serviços REST no Java EE. O principal objetivo é trazer uma API fácil de utilizar e que simplifique o desenvolvimento sem reduzir o poder que temos ao adotar esta linha de serviços. A Tabela 1 lista os principais objetivos declarados da JSR. A Tabela 2 lista as principais questões que não serão cobertas pela JSR.
|
Objetivo |
Descrição |
|
Foco em POJOs |
A API vai oferecer um conjunto de anotações e classes/interfaces associadas que possam ser usadas com POJOs para expô-los como Recursos web. A especificação definirá o escopo e o ciclo de vida dos objetos. |
|
Explorar bem o HTTP |
HTTP é assumido como o protocolo de transporte. Será feito um claro mapeamento entre os elementos do HTTP e as classes e anotações correspondentes. A API proverá suporte de alto nível aos padrões de uso comuns do protocolo. Será flexível o suficiente para suportar aplicações HTTP como o WebDAV e o AtomPub. |
|
Independência de formato |
A API permitirá o uso de diversos content-types. O suporte aos content-types será feito de uma forma plugável que defina uma forma padrão de extensão para o suporte a novos tipos de conteúdo. |
|
Independência de container |
Será possível o deployment em qualquer servidor de aplicações Java EE e também nos containers de Servlets. |
|
Inclusão no Java EE |
A especificação definirá como será o ambiente para os Recursos em um servidor Java EE. Definirá também como uma classe de Recurso poderá utilizar funcionalidades e componentes Java EE. |
Tabela 1. Objetivos da JSR-311
|
Questão |
Descrição |
|
Suporte a versões de Java anteriores à 5.0 |
A API fará extenso uso de anotações e requer o uso de Java 5 ou posterior. |
|
Descrição, registro e descoberta de serviços |
A especificação não cobrirá nenhum destes pontos. |
|
APIs clientes |
A JSR não define APIs clientes. Espera-se que outras especificações forneçam esta funcionalidade. |
|
Pilha HTTP |
A especificação não definirá uma nova pilha HTTP. O suporte a HTTP do container será utilizado." |
