JAX-RS 2.0 em construção
Ao longo dos anos, a adoção do REST como uma arquitetura de integração fora da Web cresceu, tornando inevitável que o Java e o Java EE ganhassem uma especificação, a JSR 311, ou como a maioria conhece, JAX-RS.
No entando, assim como na maioria das boas especificações, as experiências de implementação agora estão dando feedback ao JAX-RS, com o Roberto Chinnici da Oracle (ex Sun), anunciando recentemente ...
Abaixo você encontrará um esboço da JSR JAX-RS 2.0. Os criadores pedem para mandarem os seus comentários e sugestões nas próximas semanas. Em paralelo, será trabalhado nas seções restantes marcadas como TBD, incluindo o cronograma e os termos de negócio. A ideia é enviar a JSR no começo de dezembro, para que o comitê executivo da JCP aprove até os feriados de fim de ano.
Dentre as propostas, podemos destacar:
- O pedido mais comum para o JAX-RS 2.0 é a inclusão de uma API cliente: muitas, se não todas as implementações JAX-RS oferecem alguma forma de API cliente. Esta JSR irá definir duas API cliente, ambas compatíveis com REST. - O Model-View-Controller (MVC) é um padrão comum em frameworks Web, onde é utilizado predominantemente por aplicações baseadas em HTML. Adotando a terminologia MVC, as classes de recursos do JAX-RS serão compatíveis com os controllers. Esta JSR irá especificar uma arquitetura MVC compatível com o modelo de programação JAX-RS. O Java Server Pages será especificado como um dos tipos de view. Será possível inserir outras tecnologias para a view, como por exemplo o FreeMarker ou o StringTemplate. - O JAX-RS 1.1 foi definido antes da JSR-330 ser especificada, e como resultado não utiliza as anotações da JSR 330, como @Inject. Esta JSR irá especificar uma maior integração com as anotações da 330, o que poderá substituir algumas anotações JAX-RS, como a @Context, que será marcada como deprecated ou redundante. - O JAX-RS 1.1 define um modelo de requisição/resposta síncrono no lado do servidor. Esta JSR irá especificar um modelo simples de requisição assíncrono tornando possível a resposta ser enviada assíncrona à requisição. O Servlet 3.0 pode ser utilizado para habilitar tal suporte, porém as implementações deverão escolher outra API específicas do container.
O Stefan Tilkov anunciou suporte à nova proposta, e o Jerome Louvel, desenvolvedor líder do framework Restlet , também oferecerá suporte, porém surgem algumas preocupações sobre o TCK:
A principal preocupação é sobre o acesso TCK para projetos open source, como o Restlet (http://www.restlet.org). Apesar de diversos pedidos (incluindo o programa escolar da JCP), nunca se teve acesso ao TCK. a
Bill de hÓra, um dos membros iniciais do expert group, também está posicionado a favor e oferece um grande feedback, incluindo:
"Um problema que eu vejo é que sistemas no mundo real nem sempre retornam erros do mesmo formato que o cliente solicitou. Um simples exemplo - tomcat/jetty devolvendo páginas html de erro. Nós podemos argumentar que este é um problema com o servidor. Eu gostaria de ver algo que devolve o mapeador de exceção do lado do servidor do JAX-RS. Outra possibilidade é alocar manipuladores nos códigos de resposta. "
Fonte: http://www.infoq.com/br/
Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Vídeo