Como implementar web services RESTful com Jersey

A integração entre aplicações é uma necessidade cada vez mais presente em nosso dia a dia, necessidade esta que motivou a criação de diferentes abordagens para a “integração de dados”.

Dentre tais abordagens, temos soluções mais simples, como utilizar um banco de dados compartilhado ou realizara troca de arquivos,até soluções mais elaboradas, que fazem uso de objetos distribuídos, como COM(Component Object Model) e CORBA (Common Object Request Broker Architecture).

No entanto, nem a solução COM e nem a solução CORBA conseguiu padronizar de forma satisfatória a integração entre diferentes plataformas (Windows, Linux, entre outros) e diferentes linguagens de programação (PHP, C#, Java, etc.).

Diante desse cenário, os web services surgiram como uma ótima solução e com eles tornou-se possível a troca de informações entre sistemas de forma padronizada.

Como exemplo, podemos citar as aplicações de comércio eletrônico, que obtêm informações do endereço do cliente através do serviço dos Correios dado um CEP sem conhecer a plataforma onde encontra-se o serviço e em qual linguagem de programação ele foi implementado.

Entre as abordagens existentes atualmente para a implementação de web services estão o protocolo SOAP (Simple Object Access Protocol) e o REST (Representational State Transfer) e ambos funcionam sobre o protocolo HTTP, protocolo padrão para a transferência ou troca de dados na web.

Os web services implementados com SOAP usam um protocolo de mesmo nome para a transferência de mensagens no formato XML sobre o protocolo HTTP e esse XML é constituído basicamente por um elemento raiz chamado Envelope o qual contém dois sub elementos, Header e Body.

O elemento Header é opcional na mensagem e dentro dele são passadas informações de controle como, por exemplo, dados para assinatura digital, IP de origem, dados para autenticação, entre outros. Já o elemento Body é obrigatório e contém a informação a ser transportada para seu destino final, como o nome do método que será invocado e o objeto da requisição serializado.

Além disso, ele pode conter um elemento opcional chamado Fault, usado para carregar as mensagens de status e erros nas transações.

Como no protocolo SOAP a transferência de mensagens entre origem e destino se dá somente através de mensagens XML, haverá um processamento considerável tanto na origem quanto no destino para transcrever os elementos de controle, além do necessário para serializar e desserializar os objetos contidos na mensagem, tornando tal protocolo mais lento.

Tal fato se torna ainda mais relevante em situações onde há limitações de recursos (hardware e memória, por exemplo), o que indica que a adoção de SOAP nestes casos não é uma escolha adequada.

Por outro lado, os web services REST são mais simples e leves, pois usam somente o protocolo HTTP para a transferência de mensagens, não adotando elementos adicionais de controle e nem elementos adicionais para o envio das mensagens além dos existentes no protocolo HTTP.

Outro diferencial é que eles são mais flexíveis, pois não impõem restrições no formato das mensagens, ou seja, o desenvolvedor pode optar pelo formato mais adequado à sua necessidade, como JSON, texto, XML, entre outros.

Com isso, aplicações que necessitam de simplicidade na troca de informações e maior flexibilidade no desenvolvimento se beneficiam da arquitetura REST como, por exemplo, serviços remotos acessados via smartphones e PDAs.

A partir do que foi analisado, serão apresentados neste artigo os principais conceitos relacionados à arquitetura REST e demonstrado, na prática, como é simples desenvolver uma aplicação com esta arquitetura. Para isso, será adotada a IDE NetBeans, a IDE Eclipse juntamente com o servidor web Tomcat, JAX-RS e o Jersey.

REST

O REST é um estilo arquitetural para sistemas distribuídos que utiliza o protocolo HTTP e outras tecnologia existentes na web, como XML, JSON, entre outras, para a criação de web ...