Eu estou atualmente implementando alguns web services Restful, e estou avaliando opções para alguns pedaços do desenvolvimento. Eu já sabia que existia uma JSR para web services REST, mas ainda não tinha lido a mesma.Agora há pouco li a JSR-311, que definirá padrões de implementação Java para uma API Rest, do lado do servidor. A parte de implementação de clientes será tratada em outra(s) JSR(s) .
Esta JSR é bastante interessante, e já pude ver nela o tratamento de coisas muito úteis. De principal destaque para mim está a abordagem de mapeamento de URIs em recursos e métodos e a questão do mapeamento de classes Java para dados com diversos content-types.
Em relação às URIs, há a definição de regras para mapear URIs em classes e métodos, instanciando as classes necessárias e invocando os métodos adequados. Suponha por exemplo uma requisicao HTTP PUT na URI /usuario/16728/produto/228/configuracao/. Em um protocolo definido por mim, isto representaria uma atualização nas configurações do Produto 228 para o Usuário 16728. Um ser humano consegue entender isso sem tantos problemas, mas uma implementação manual destes mapeamentos e o parsing dos parâmetros podem ser coisas bem trabalhosas. A JSR 311 utiliza várias annotations para conseguir definir o encadeamento de classes e métodos a partir da URI utilizada, e isto faz com que você consiga desenvolver em Java normalmente e ter as suas classes instanciadas e invocadas com URIs tão flexíveis quanto você queira. Muito bom ter isso como recurso, pois implementar na mão é bem trabalhoso.
Outra coisa muito interessante é a maneira de mapear classes Java para diversos content-types. Isso é algo fundamental para uma implementação Restful com bastante flexibilidade E possivelmente alta performance. A idéia por trás disso é que o servidor recebe uma requisição de um cliente e verifica quais são os content-types que o cliente aceita. Com base nestas informações, o servidor escolhe a forma que irá utilizar para transmitir os dados.
Suponha por exemplo que uma aplicação PHP está se comunicando com seu servidor, e ele lhe informa que aceita os content-types text/plain, text/xml e application/json. O servidor pode escolher qual formato utilizar para o envio e possivelmente o envio com formato json facilita bastante a aplicação PHP. Este mesmo servidor pode receber requisições de uma outra aplicação Java, que preferencialmente receberá do seu servidor um stream binário, que terá a melhor performance de todas as opções.
O uso desta abordagem dos mapeamentos em content-types permite que sua aplicação tenha ao mesmo tempo alta interoperabilidade e alta performance. Você conseguirá se comunicar com várias plataformas e aplicações diferentes, e continuará tendo a opção de alta performance, caso seja uma aplicação da mesma plataforma. Você não consegue isso com web services WS-*. Eles não têm tamanha flexibilidade.
O meu próximo passo agora será analisar com detalhes o Jersey, a implementação de referência desta JSR. A especificação em si ainda está um tanto crua, pois ainda é um early draft. Já pude ver vários pontos interessantes, mas a definição ainda está sujeita a muitas modificações. Vou avaliar agora o que o Jersey já oferece e torcer para que ele já tenha componentes fáceis de usar e flexíveis. A proposta dele é excelente, vamos ver se a implementação consegue oferecer estes recursos sem amarrar muito as decisões de projeto.
One Response
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Continuing the Discussion