Pesquisar este blog

segunda-feira, 20 de outubro de 2014

Implementando um WebService REST com o PlayFramework no Java

REST/RESTful (representaçao do estado de transferência) é o nome dado a definição das regras, este termo surgiu no ano de 2000 na dissertação de Roy Fielding. Esta é uma decisão arquitetural, é uma abstração da arquitetura da WWW. Um cliente de um serviço REST é bem desacoplado, pois o REST possui regras bem flexíveis.
A definiçao REST é independente de protocolo, ele não está acoplado ao HTTP.
Para construir um aplicativo cliente de uma implementação REST as únicas informações necessárias são: o ponto de entrada e o tipo de arquivos que ele irá utilizar para trocar informações.
REST não é apenas um mapa CRUD dos métodos HTTP, apesar de muitos aplicativos fazerem este tipo de mapeamento.
GET é o método HTTP utilizado para requerer algum tipo de informação do servidor
PUT é um método HTTP que deve ser utilizado para alterar os dados, somente quando todas as informações que estiverem sendo enviadas foram alteradas, ou seja, ele é um update completo dos dados e não um update parcial (de apenas um campo).
POST, por definição é uilizado para fazer tudo o que os outros métodos http não podem fazer, com isso pode-se usá-lo para inserir informações (criar) e para alterar informações, desde que de maneira parcial.

Estilo arquitetural do REST

O estilo arquitetural do REST podem ser aplicadas aos webservices, o que os caracterizarão como webservices RESTful quando eles aplicarem as regras descritas abaixo:
As propriedades do REST devem ser aplicadas aos componentes, conectores e aos elementos de dados.

Client Server

Uma interface uniforme separa os clientes dos servidores, o que caracteriza uma separação de responsabilidades. Os clientes REST não podem ficar responsáveis pelo armazenamento de dados, o que deverá ficar restrito aos servidores, o que aumenta a portabilidade do código do cliente. Os servidores não devem se preocupar com o estado do usuário nem com a interface do cliente, com isso eles ficam mais simples e escaláveis.

Stateless

A comunicação entre o cliente e o servidor acontece sem nenhuma informação de contexto do cliente/usuário ser registrada nos servidores entre as requisições. Cada requisição do cliente deverá conter todas as informações necessárias para ela ser completada. O estado da sessão é mantido no cliente, porém é importante notar que o estado da sessão poderá ser transferido entre os servidores afim de manter o estado de persistência por um período temporal e controlar a autenticação.

Cache

Assim como na internet, os clientes podem cachear as respostas, porém as respostas possuem a capacidade de se definirem como cacheáveis ou não. Um cacheamento bem administrado pode evitar muitas chamadas aos servidores, o que contribui para o aumento da performance e escalabilidade daquele serviço.

Sistema em Camadas

Um cliente nunca deve saber se ele está conectado diretamente ao servidor final, ou se existe algum processo no meio do caminho. Servidores intermediários podem realizar um trabalho de balanceamento de carga ou proverem caches distribuídos, além de também forçar políticas de segurança.

Interfaces uniformes

A uniformização das interfaces é um dos pontos mais importantes do design de Serviços REST. Elas servem para simplificar e desacoplar a arquitetura, o que possibilita a evolução independente de cada parte do sistema. Existem quatro regras da uniformização das interfaces:

Identificação dos recursos

Recursos individuais deverão ser identificados nas requisições, por exemplo utilizando URIs em um serviço REST baseado na web. Estes recursos devem ser conceitualmente separados das respresentações que serão retornadas aos clientes, por exemplo um servidor pode enviar dados em formatos JSON, XML ou HTML, mas nenhum deles deverá ter a mesma representação que elas possuem no armazenamento daquele servidor. Os dados devem possuir estruturas diferentes no banco de dados e nos serviços.

Manipulação dos recursos através destas representações

Quando um cliente possuir uma instância de um recurso, incluindo metadados, ele deve possuir as informações necessárias para modificar ou apagar aquela instância.

Mensagens autodescritivas

Cada mensagem deverá conter todas as informações necessárias para o processamento daquela mensagem, por exemplo uma mensagem que carrega um pdf, deverá conter esta informação nela para que os seus dados sejam processados corretamente.

Hipermedia como engine de estado da aplicação

Os clientes podem fazer transições de estado somente através das ações que foram identificadas com a hipermedia do servidor, ou seja, todas as ações devem estar descritas em algum arquivo loalizado no servidor em que a implementação do REST estiver disponível.

Apresentação
Este post continua aqui com exemplos de código

Nenhum comentário:

Postar um comentário