REST

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é uma abstração da arquitetura da World Wide Web, mais precisamente, é um estilo arquitetural que consiste de um conjunto coordenado de restrições arquiteturais aplicadas a componentes, conectores e elementos de dados dentro de um sistema de hipermídia distribuído. O REST ignora os detalhes da implementação de componente e a sintaxe de protocolo com o objetivo de focar nos papéis dos componentes, nas restrições sobre sua interação com outros componentes e na sua interpretação de elementos de dados significantes.

O termo transferência de estado representacional foi introduzido e definido em no ano de 2000 por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da internet, em uma tese de doutorado (PHD) na UC Irvine.[1] A REST tem sido aplicada para descrever a arquitetura web desejada, identificar problemas existentes, comparar soluções alternativas e garantir que extensões de protocolo não violem as principais restrições que fazem da web um sucesso. Fielding desenvolveu a REST em colaboração com seus colegas durante o mesmo período em que trabalhava no HTTP 1.1 e nos Identificadores de Recursos Uniformes (URI).

O estilo arquitetural de REST também é aplicado no desenvolvimento de web services. Pode-se caracterizar os web services como "RESTful" se eles estiverem em conformidade com as restrições descritas na seção restrições arquiteturais. Veja a seção aplicado a web services se você estiver interessado apenas na aplicação de REST para APIs web.

Cquote1.svg A REST (Transferência do Estado Representativo) é pretendida como uma imagem do design da aplicação se comportará: uma rede de websites (um estado virtual), onde o utilizador 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 utilizador e apresentada para seu uso. Cquote2.svg
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 mais 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 RPC 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 são freqüentemente chamados de RESTful'.

Princípios[editar | editar código-fonte]

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

  • 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 necessitam gravar nenhum estado das comunicaçõ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 reescrita 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 si 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 registos ou outra infraestrutura adicional.

Recursos[editar | editar código-fonte]

Um conceito importante em REST é a existência de recursos (elementos de informação), que podem ser usados utilizando um identificador 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 grande discussão, sem a distinção entre recursos e suas representações é demasiado utópico o 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 informaçã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 outra, 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.

REST e RPC[editar | editar código-fonte]

Uma aplicação web REST requer um enfoque de desenho diferente a uma aplicação baseada em RPCs. No RPC, dá-se ênfase à 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 está na diversidade de recursos, nos nomes; por exemplo, uma aplicação REST poderia definir os seguintes tipos de recursos:

 Usuario {}
 Localizacao {}

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 utiliza-se geralmente para ações com efeitos colaterais, como enviar uma ordem de compra.

Por exemplo, o registo para um Utilizador poderia ter o seguinte aspecto:

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

Para atualizar a localização do utilizador, um cliente REST poderia primeiro chamar um registo XML anterior usando GET. O cliente depois modificaria o arquivo para mudar a localização e submetê-la-ia para o servidor utilizando HTTP PUT.

Note-se que o HTTP não proporciona nenhum recurso padrão para descobrir recursos -- não há nenhuma operação LIST ou FIND em HTTP, que se corresponda às operações list*() e find*() como por exemplo em RPC. No 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 na aplicação colocando URLs adicionais para mostrar ou encontrar 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 utilizadores 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 gerir as ligações.

Implementações públicas[editar | editar código-fonte]

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 arquivos/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áfego)
  • eBay oferece uma interface REST.
  • O Projeto "Seniores Canada On-line" do Governo do Canadá oferece um interface REST [2] .
  • Bloglines oferece uma API baseada em REST.
  • Yahoo! oferece uma API em REST.
  • O mecanismo Ruby on Rails suporta aplicações REST utilizando o padrão MVC.
  • O publicador de objetos do Zope.
  • Os Frameworks Python possuem pleno suporte a REST, por exemplo: Django, Flask
  • Os Frameworks para desenvolvimento em PHP, Zend Framework e CakePHP possuem componentes para criação de aplicações REST.


De qualquer forma, deve-se ter em mente que as aplicações descritas acima não são totalmente escritas puramente em REST, 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"[3] .

Ver também[editar | editar código-fonte]

Referências

Ligações externas[editar | editar código-fonte]