REST

Origem: Wikipédia, a enciclopédia livre.

A Transferência de Estado Representacional (Representational State Transfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídia distribuídos como a World Wide Web. O termo se originou no ano de 2000, em uma tese de doutorado (PHD) sobre a web escrita por Roy Fielding, um dos principais autores as especificação do protocolo HTTP que é utilizado por quase todos os sites da internet.

A Transferência do Estado Representacional é pretendida como uma imagem do design da aplicação se comportará: uma rede de websites (um estado virtual), onde o usuário progride com uma aplicação selecionando as ligações (transições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao usuário e apresentada para seu uso.

Dr.Roy Fielding

O termo REST, se referia originalmente a um conjunto de princípios de arquitectura (descritos mais abaixo), na actualidade se usa no sentido mas amplo para descrever qualquer interface web simples que utiliza XML e HTTP (ou YAML, JSON, ou texto puro), sem as abstrações adicionais dos protocolos baseados em padrões de trocas de mensagem como o protocolo de serviços web SOAP. É possível desenhar sistemas de serviços web de acordo com o estilo arquitetural REST descrito por Fielding, e também é possível desenhar interfaces XMLHTTP de acordo com o estilo de chamada de procedimento remoto mas sem utilizar SOAP. Estes usos diferentes do termo REST causam certa confusão em discussões técnicas, onde RPC não é um exemplo de REST.

Os sistemas que seguem os princípios REST se chamam com frequência de RESTful; os defensores mais ferrenhos do REST são chamados pelos mesmos de RESTafarianos.

[editar] Princípios

REST afirma que a web já desfrutou de escalabilidade como resultado de uma série de desenhos fundamentais chaves:

Um protocolo cliente/servidor sem estado: cada mensagem HTTP contém toda a informação necessária para compreender o pedido. Como resultado, nem o cliente e nem o servidor necesitam gravar nenhum estado das comunições entre mensagens. Na prática, muitas aplicações baseadas em HTTP utilizam cookies e outros mecanismos para manter o estado da sessão (algumas destas práticas, como a reescritura de URLs, não são permitidas pela regra do REST).

Um conjunto de operações bem definidas que se aplicam a todos os recursos de informação: HTTP em sí define um pequeno conjunto de operações, as mais importantes são POST, GET, PUT e DELETE. Com frequência estas operações são combinadas com operações CRUD para a persistência de dados, onde POST não se encaixa exatamente neste esquema.

Uma sintaxe universal para identificar os recursos. No sistema REST, cada recurso é unicamente direcionado através da sua URI.

O uso de hipermídia, tanto para a informação da aplicação como para as transições de estado da aplicação: a representação deste estado em um sistema REST são tipicamente HTML ou XML. Como resultado disto, é possível navegar com um recurso REST a muitos outros, simplesmente seguindo ligações sem requerer o uso de registros ou outra infraestrutura adicional.

[editar] Recursos

Um conceito importante em REST é a existência de recursos (elementos de informação), que podem ser usados utilizando um identificar global (um Identificador Uniforme de Recurso) para manipular estes recursos, os componentes da rede (clientes e servidores) se comunicam através de uma interface padrão (HTTP) e trocam representações de recursos (os arquivos ou ficheiros são recebidos e enviados) - é uma questão polêmica e gera muito debate, sem a distinção entre recursos e suas representações é demasiado platônica para seu uso prático na rede, onde é popular na comunidade RDF.

O pedido pode ser transmitido por qualquer número de conectores (por exemplo clientes, servidores, caches, etc.) mas não poderá ver mais nada do seu próprio pedido (conhecido com separação de capas, outra restrição do REST, que é um princípio comum com muitas outras partes da arquitetura de redes e da imformação). Assim, uma aplicação pode interagir com um recurso conhecendo o identificador do recurso e a ação requerida, não necessitando conhecer se existem caches, proxys ou qualquer outra coisa entre ela e o servidor que guarda a informação. A aplicação deve compreender o formato da informação de volta (a representação), que é geralmente um documento em formato HTML ou XML, onde também pode ser uma imagem ou qualquer outro conteúdo.

[editar] REST e RPC

Uma aplicação web REST requer um enfoque de desenho diferente a uma aplicação baseada em chamadas de procedimento remotos. No RPC, se põe ênfase na diversidade de operações do protocolo, ou verbos; por exemplo uma aplicação RPC poderia definir operações como:

getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()

Em REST, ao contrário, a ênfase se pões na diversidade de recusros, nos nomes; por exemplo, uma aplicação REST poderia definir os seguintes tipos de recursos:

 Usuario {}
 Localizacion {}

Cada recurso teria seu próprio identificador, como http://www.example.org/locations/us/ny/new_york_city. Os clientes trabalhariam com estes recursos através das operações padrão de HTTP, como o GET para chamar uma cópia do recurso. Observa-se como cada objeto tem sua própria URL e pode ser facilmente cacheado, copiado e guardado como marcador. POST se utiliza geralmente para ações com efeitos laterais, como enviar uma ordem de compra.

Por exemplo, o registro para um Usuário poderia ter o seguinte aspecto:

<usuario>
 <nombre>Maria Juana</nombre>
 <gonero>feminino</genero>
 <localizacion href="http://www.example.org/locations/us/ny/new_york_city"
           >Nova York, NY, US</localizacion>
</usuario>

Para atualizar a localização do usuário, um cliente REST poderia primeiro chamar um registro XML anterior usando GET. O cliente depois modificaria o arquivo para mudar a localização e a subiria para o servidor utilizando HTTP PUT.

Nota-se que os verbos HTTP não proporcionam nenhum recurso padrão para descobrir recursos -- não há nenhuma operação LIST ou FIND em HTTP, que se corresponderiam com as operações list*() e find*() como por exemplo em RPC. Em seu lugar, as aplicações baseadas em dados REST resolvem o problema tratando uma coleção de resultados de busca como outro tipo de recurso, o que requer que os engenheiros de software desenhem a aplicação colocando URLs adicionais para mostrar ou buscar cada tipo de recurso.

Por exemplo, um pedido GET HTTP sobre a URL http://www.example.org/locations/us/ny/ poderia devolver uma lista de arquivos em XML com todas as localizações possíveis em Nova Iorque, e outra, um pedido GET para URL http://www.example.org/users?seunome=Michaels poderia devolver uma lista de todos os usuários com o apelido "Michaels".

REST proporciona algumas indicações sobre como realizar este tipo de ação como parte de sua restrição "hipermídia como o meio de estado da aplicação", o que sugere o uso de uma linguagem de marcação (como um formulário HTML) para especificar consultas parametrizadas.

A iniciativa OpenSearch da A9.com tenta padronizar as buscas usando REST estabelecendo especificações para descobrir recursos e um formato genérico para utilizar sistemas baseados em REST, incluindo o RDF, XTM, Atom, RSS (e suas várias formas) e XML com XLink para gerenciar as ligações.

[editar] Implementações públicas

Dado que a definição de REST é muito ampla, é possível afirmar que existe um enorme número de aplicações REST na rede (praticamente qualquer coisa acessível mediante um pedido HTTP GET). De forma mais restritiva, em contra posição aos serviços web e ao RPC, REST se pode encontrar em diferentes áreas da web:

Na blogosfera -o universo dos blogs- está, em sua maior parte, baseado em REST, dado que implica chamar ficheros XML (em formato RSS ou Atom) que contem listas de ligações a outros recursos.
Amazon.com oferece sua interface tanto em formato REST como em formato SOAP (sendo a versão REST a que recebe maior tráfico)
eBay oferece uma interface REST [1].
O Projeto "Seniors Canada On-line" do Governo do Canadá oferece um interface REST descrito aqui.
Bloglines oferece uma API baseada em REST [2].
Yahoo! oferece uma API em REST [3].
O mecanismo Ruby on Rails suporta aplicações REST utilizando o padrão MVC.
O publicador de objetos do Zope.

De qualquer forma, deve ter em mente que as aplicações descritas acima não são totalmente escritas em REST puramente, isto é, não respeitam todas as restrições que impõe a arquitetura REST. E sim, todas são inspiradas em REST e respeitam os aspectos mais significativos e restritivos da sua arquitetura, em particular a restrição de "interface uniforme". Estes serviços são denominados "Acidentalmente RESTful".