REST

Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de RESTful)
Saltar para a navegação Saltar para a pesquisa

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é um estilo de arquitetura que define um conjunto de restrições e propriedades baseados em HTTP. Web Services que obedecem ao estilo arquitetural REST, ou web services RESTful, fornecem interoperabilidade entre sistemas de computadores na Internet. Os web services compatíveis com REST permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos da Web usando um conjunto uniforme e predefinido de operações sem estado. Outros tipos de web services, como web services SOAP, expõem seus próprios conjuntos arbitrários de operações.[1]

"Recursos web" foram primeiramente definidos na World Wide Web como documentos ou arquivos identificados por seus URLs. Entretanto, hoje eles possuem uma definição muito mais genérica e abstrata que abrangem todas as coisas ou entidades que podem ser identificadas, nomeadas, endereçadas ou manipuladas qualquer que seja a maneira, na web. Em um web service RESTful, requisições feitas a um URI de recurso extrairá uma resposta que pode estar em XML, HTML, JSON ou algum outro formato. A resposta pode confirmar que alguma alteração foi realizada para o recurso armazenado e a resposta pode fornecer ligações de hipertexto para outros recursos ou coleções de recursos relacionados. Quando o HTTP é usado, como é mais comum, as operações disponíveis são GET, POST, PUT, DELETE e outros métodos HTTP CRUD pré-definidos.

Por meio da utilização de um protocolo sem estado e operações padrões, sistemas REST destinam-se para desempenho rápido, confiabilidade e habilidade de crescimento, por meio da reutilização de componentes que podem ser gerenciados e atualizados sem afetar o sistema como um todo, mesmo que esteja em execução.

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 apresentado e definido 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.[2] Sua dissertação explicou os princípios da REST que ficou conhecida como "modelo de objeto HTTP" no início de 1994, e foi usada nos padrões HTTP 1.1 e Identificadores de Recursos Uniformes.[3][4][5] O termo destina-se a evocar uma imagem de como uma aplicação web bem projetada se comporta: ela é uma rede de recursos web (uma máquina de estado virtual) onde o usuário progride ao longo da aplicação por meio de seleção de ligações, como /user/tom, e operações como GET ou DELETE (transições de estado), resultando no próximo recurso (representando o próximo estado da aplicação) sendo transferida ao usuário para sua utilização.

História[editar | editar código-fonte]

O termo REST se referia, originalmente, a um conjunto de princípios de arquitetura (descritos mais abaixo), na atualidade se usa no sentido mais amplo para descrever qualquer interface web simples que utiliza XML (ou YAML, JSON, ou texto puro) e HTTP, 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 projetar sistemas de serviços Web de acordo com o estilo arquitetural REST descrito por Fielding, e também é possível projetar 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.

   REST é um termo definido para "Transferência de Estado Representacional"(Representational State Transfer), criado no ano 2000 por Roy Fielding em sua tese de mestrado no qual ele descreve um design de arquitetura de software construído para servir aplicações em rede. A aplicação mais comum de REST é a própria World Wide Web, que utilizou REST como base para o desenvolvimento do HTTP 1.1.

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

REST afirma que a Web já desfrutou de escalabilidade como resultado de uma série de conceitos de projeto 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 registros 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?nome=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 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.[6]
  • Bloglines oferece uma API baseada em REST.
  • Yahoo! oferece uma API em REST.
  • O framework 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, Laravel ,Zend Framework e CakePHP possuem componentes para criação de aplicações REST.
  • Os Frameworks REST NodeJS: Gugamarket - ver mais em Nodeframework.
  • Os Frameworks para desenvolvimento Web em Groovy,Grails e Spring-boot suportam aplicações REST utilizando padrão MVC.


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".[7]

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

Referências

  1. «Web Services Architecture». World Wide Web Consortium. 11 de fevereiro de 2004. 3.1.3 Relationship to the World Wide Web and REST Architectures. Consultado em 29 de setembro de 2016. 
  2. Fielding, Roy, Representational State Transfer (REST) (em inglês), UCI 
  3. RFC 1945
  4. RFC 2616
  5. Fielding, Roy Thomas (2000). «Chapter 6: Experience and Evaluation». Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web. This chapter describes the experience and lessons learned from applying REST while authoring the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI), the two specifications that define the generic interface used by all component interactions on the Web, as well as from the deployment of these technologies in the form of the libwww-perl client library, the Apache HTTP Server Project, and other implementations of the protocol standards. 
  6. Big, public REST application: Seniors Canada Online (em inglês)
  7. Accidentally RESTful (em inglês)

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