Falaremos também sobre a API JAX-RS (ou Java
API for RESTful Web Services) e sua implementação de referência: o Jersey. Por
fim, ao final deste artigo você estará apto a configurar o ambiente de
desenvolvimento e saberá como criar a aplicação propriamente dita,
compreendendo as partes do código mais relevantes para esse tipo de
implementação.
Autores: Carlos Antônio Martins e Nelio Alves
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 services. Esse termo foi citado pela primeira vez por Roy Fielding (um dos criadores do protocolo HTTP) no ano de 2000, em sua tese de doutorado.
A ideia por trás do mesmo é que em vez de usar mecanismos complexos como CORBA ou SOAP para a troca de mensagens entre cliente e servidor, utiliza-se o protocolo HTTP, opção mais simples e fácil e que já possui os recursos necessários para tal.
Em uma arquitetura baseada em REST, tudo é tido como recursos (elementos de informação), os quais são identificados por URIs (Uniform Resource Identifiers). Um recurso pode ser qualquer informação, seja ela os dados de uma pessoa, de uma tarefa ou mesmo um post em um blog.
Por exemplo, a previsão do tempo de uma determinada cidade pode ser considerada um recurso. Na internet, recursos são normalmente representados como uma página HTML, um arquivo de imagem ou mesmo um documento XML, os quais podem ser acessados utilizando uma interface comum baseada nos métodos do protocolo HTTP: GET, PUT, POST e DELETE.
Neste momento é importante destacar que na arquitetura REST os recursos são totalmente desacoplados do formato retornado para o cliente. Assim, um registro do banco de dados no servidor pode ser enviado ao cliente como um arquivo XML, JSON, uma página HTML, entre outras opções.
Atualmente, os formatos mais utilizados para representar os recursos são: JSON, XML, páginas HTML, documentos PDF e arquivos JPG, diversidade esta que facilita a integração com diferentes tipos de clientes, como browsers, smartphones, tablets, aplicativos desktop, entre outros.
Ressalta-se ainda que o REST é um estilo arquitetural e não um modelo formalmente definido, como muitos pensam. Note que não existe uma definição detalhada e padronizada de como a troca de mensagens entre cliente e servidor deve ocorrer.
Isto varia de acordo com a interpretação de cada pessoa. Em outras palavras, cada empresa/desenvolvedor pode definir seus serviços com um estilo próprio, embora deva considerar todos os princípios e restrições que a arquitetura descreve, originando, nestes casos, os web services RESTful.
Princípios do REST
Conforme definido por Roy Fielding, o REST possui um conjunto de princípios que descrevem como os padrões da web, como HTTP e URIs, devem ser usados. A argumentação é que a adesão a estes princípios em um projeto faz com que o sistema explore melhor a arquitetura web para benefício próprio. Em resumo, os cinco princípios que norteiam o REST são:
1. Utiliza o conceito de recursos. Um recurso é tudo que possa ser requisitado a um servidor. Por exemplo, um arquivo texto, uma página HTML, uma imagem, etc.;
2. Cada recurso deve possuir um ID para identificá-lo na interação entre as partes envolvidas. O mais comum é utilizar o URI do documento;
3. Uso de padrões como HTTP, HTML ou XML;
4. Um recurso pode ter várias representações, como XML, texto, HTML, JSON, entre outras, as quais são conhecidas como media types;
5. A comunicação entre cliente e servidor é feita através do protocolo HTTP e sem estado (stateless), ou seja, cada requisição deve conter todas as informações necessárias para que o servidor consiga entendê-la e processá-la adequadamente, sem utilizar informações vindas de outras requisições.
Restrições do estilo REST
Segundo Roy Fielding, para que os princípios anteriormente apresentados sejam respeitados, um conjunto de restrições deve ser seguido. Portanto, na iteração entre os componentes dos sistemas, as restrições a seguir devem estar presentes (as cinco primeiras restrições são obrigatórias e a última é opcional):
1. Cliente-Servidor: Ao separar os papeis do cliente (consumidor do serviço) dos papeis do servidor (provedor do serviço), melhoramos a portabilidade da interface do usuário em ambientes multiplataforma e a escalabilidade pela simplificação dos componentes no servidor;
2. Stateless (sem estado): O servidor não deve armazenar informações de contexto para atender as requisições dos clientes;
3. Interface Uniforme: Significa que os recursos gerenciados serão manipulados de maneira uniforme, ou seja, a informação é transferida de forma padronizada para todas as aplicações e não apenas para uma em específico;
4. Multicamada: Permite a composição da arquitetura em camadas hierárquicas, de forma a restringir o comportamento dos componentes, impedindo que cada um “veja” além da camada com a qual ele interage diretamente;
5.
Cache: Como muitos clientes acessam um
mesmo servidor, e muitas vezes requisitando os mesmos recursos, é necessário
que estas respostas p ...
