Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Você já imaginou como seria a vida sem internet? Através da rede mundial conseguimos pagar nossas contas, ficar em contato com a família e amigos, visitar lugares do mundo, ganhar dinheiro, gastar dinheiro, assistir filme, disponibilizar nossos filmes para que os outros possam assistir e muito mais.

Como desenvolvedores, construímos sistemas que as pessoas irão utilizar simplesmente usando seus navegadores. É algo espetacular: você desenvolve um sistema complexo, em qualquer plataforma que desejar e, em poucos minutos, sua aplicação pode estar disponível para todas as pessoas do mundo! Concluímos então que a web cumpre seu objetivo. Alguns vão além e dizem que a web é o sistema de maior sucesso na história da informática. Mas quais são os princípios que estão por trás desse sucesso? Com certeza a onipresença e ubiquidade da web estão relacionadas a alguns fatores específicos. Roy Fielding, um dos autores da especificação do protocolo HTTP, em sua tese de doutorado, descreveu um estilo arquitetural que une os princípios da web e o chamou de REST (REpresentational State Transfer). REST é um estilo arquitetural para sistemas de hipermídia distribuídos que permite a construção de aplicações e web services que irão usufruir das mesmas vantagens da rede mundial.

Por outro lado, “Aplicações Enterprise” distribuídas não compartilhavam o mesmo sucesso da web, pois muita complexidade e soluções específicas eram aplicadas para atingir esse objetivo. Uma abordagem contemporânea na construção de sistemas distribuídos é através do uso de web services. Web Services são amplamente utilizados, pois trazem a independência de plataforma e se utilizam de padrões abertos.

Unindo o melhor da web e a abordagem mais utilizada na integração de sistemas, temos os web services que seguem o estilo arquitetural REST e são conhecidos como RESTful. O uso desses tipos de serviços web tem crescido bastante nos últimos anos, ganhando evidência no meio antes dominado por arquiteturas tradicionais. Pensando nesse crescimento, foi criada a especificação JSR-311, ou JAX-RS, que permite com facilidade a criação de sistemas que seguem o estilo arquitetural REST.

No presente artigo vamos mostrar uma implementação dessa especificação chamada RESTEasy, no entanto, mostraremos também o que o RESTEasy oferece além da implementação, como a integração com famosos frameworks do mercado, as ferramentas para construção de clientes de web services RESTful, interceptores, entre outras coisas.

Brevemente RESTful WEB Services

REST, REpresentational State Transfer, foi definido no capítulo 5 da famosa tese de Roy Fielding. Basicamente é um conjunto de princípios retirados da web com algumas restrições. O livro Java SOA Cookbook apresenta um conceito interessante sobre REST: “The idea of REST is essentially a reverse-engineering of how the Web works”, que em português pode ser traduzido como: “A ideia de REST é essencialmente uma engenharia reversa de como a Web funciona”. RESTful WEB Services, por sua vez, são web services que seguem os princípios dominantes da web.

Primeiramente temos o que chamados de recurso. Segundo a tese de doutorado de Fielding, recurso é tudo aquilo que podemos nomear. No livro RESTful WEB Services, eles são definidos como tudo que podemos criar um link para acesso.

Esses recursos podem ser representados de várias formas, como por exemplo, utilizando os formatos mais utilizados na WEB: JSON, XML e YAML. Essas representações, no entanto, não são ligadas ao conteúdo do recurso, ou seja, um recurso pode ser representado de diversas formas, mas ainda continuará sendo o mesmo.

Assim como os recursos não dependem da representação, eles também não devem depender da forma de acesso. Devem ser acessíveis através de uma interface uniforme, o que significa que devemos interagir com eles independente de qual recurso estivermos nos referindo. Exemplificando, se nossa aplicação contém Cliente e Produtos, a forma de recuperá-los deve ser a mesma, isto é, deve-se utilizar o mesmo método.

Mas como definir o que você está acessando no servidor se o acesso é feito através de uma interface uniforme e não específica por recursos? Isso nos leva a outro princípio no qual cada recurso deve ser identificado unicamente. Isso vem de uma das características mais interessantes, e talvez a mais revolucionária, da Web: links. Se você quer que um amigo veja um artigo publicado na WEB, você vai enviar o link para ele e ele vai conseguir acessar. Embora pareça algo comum para nós hoje, imagine como a vida era sem links antes da internet.

Outro princípio bastante discutido do REST é a falta de estado, onde não devemos exigir nenhum estado anterior do cliente no servidor, uma requisição deve ser suficiente para realizar determinada operação e o servidor não precisa manter nada dessa requisição. Um exemplo que quebra esse conceito é o uso de sessões. Alguns recursos na web só são acessíveis quando logamos no site e após o login é criada uma sessão. Em RESTful WEB Services isso seria “ilegal”, pois exigimos um estado anterior do cliente. Serviços stateful também atrapalham a “linkagem” citada no parágrafo anterior. Por outro lado, o princípio de serviços sem estado facilita a escalabilidade de nossas aplicações e o cache de nossos recursos.

Não ter estado não significa necessariamente que não podemos criar aplicações que normalmente dependeriam de uma sessão para serem implementadas. A "