REST

Na informática e engenharia de software, Representational State Transfer (abreviado REST), em português Transferência de Estado Representacional, é um estilo de arquitetura de software, criado em 2000 por Roy Fielding, que define um conjunto de restrições a serem usadas para a criação de um tipo especial de serviços-Web, denominados Web services RESTful, que fornecem interoperabilidade entre sistemas de computadores na Internet; RESTful permite 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 (requisição e resposta independentes). Outros tipos de Web services, como Web services SOAP, expõem seus próprios conjuntos de operações arbitrários.^[1]

"Recursos da Web" foram definidos pela primeira vez na World Wide Web como documentos ou arquivos identificados por suas URL. No entanto, hoje eles têm uma definição muito mais genérica e abstrata que engloba qualquer objeto ou entidade que pode ser identificada, endereçada, manipulada, da forma que for, na Web. Em um Web service RESTful, as solicitações feitas ao URI de um recurso provocará uma resposta com uma carga útil formatada em HTML, XML, JSON, ou formato similar. A resposta pode confirmar que alguma alteração foi feita no recurso armazenado e a resposta pode fornecer links de hipertexto para outros recursos ou conjuntos de recursos relacionados. Quando o HTTP é usado, como é o mais comum, as operações (métodos HTTP) disponíveis são GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS e TRACE.^[2]

Usando um protocolo sem estado e operações padrão, os sistemas RESTful buscam desempenho, confiabilidade e capacidade de crescimento rápido, reutilizando componentes que podem ser gerenciados e atualizados sem afetar o sistema como um todo, mesmo enquanto estiver em execução.

O termo transferência de estado representacional foi introduzido e definido em 2000 por Roy Fielding em sua tese de doutoramento.^[3]^[4] A dissertação de Fielding explicou os princípios REST que eram conhecidos como "modelo de objeto HTTP", a partir de 1994, e foram usados no projeto dos padrões HTTP 1.1 e URI (Uniform Resource Identifiers).^[5]^[6] O termo destina-se a evocar uma imagem de como um aplicativo da Web bem projetado se comporta: é uma rede de recursos da Web (uma máquina de estados virtuais) na qual o usuário avança pelo aplicativo selecionando identificadores de recursos, como http://www.exemplo.com/artigos/21, e operações de recursos, como GET ou POST (transições de estado do aplicativo), resultando na próxima representação do recurso (o próximo estado do aplicativo) sendo transferida para o usuário final para seu uso.

História

O termo REST se referia, originalmente, a um conjunto de princípios de arquitetura (descritos 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 doutoramento na 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

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

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

Uma aplicação web REST requer um enfoque de desenho diferente a uma aplicação baseada em RPC. 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, a ênfase está na diversidade de recursos, nos nomes; por exemplo, que 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 de 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

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/ficheiros 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.
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

Referências

↑ «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
↑ Fielding, Roy (Junho de 2014). «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4». IETF. Internet Engineering Task Force (IETF). RFC 7231. Consultado em 14 de fevereiro de 2018
↑ Fielding, Roy Thomas (2000). «Chapter 5: Representational State Transfer (REST)». Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.
↑ «Fielding discussing the definition of the REST term». groups.yahoo.com. Consultado em 8 de agosto de 2017
↑ Fielding, Roy; Gettys, Jim; Mogul, Jeffrey; Frystyk, Henrik; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (Junho de 1999). «Hypertext Transfer Protocol -- HTTP/1.1». IETF. Internet Engineering Task Force (IETF). RFC 2616. Consultado em 14 de fevereiro de 2018
↑ 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.
↑ Accidentally RESTful (em inglês)

Ligações externas

Uma Arquitetura para Serviços Web por Sérgio Nunes e Gabriel David (PDF).

[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

[rfc_7231-2] Fielding, Roy (Junho de 2014). «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4». IETF. Internet Engineering Task Force (IETF). RFC 7231. Consultado em 14 de fevereiro de 2018

[Fielding-Ch5-3] Fielding, Roy Thomas (2000). «Chapter 5: Representational State Transfer (REST)». Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine. This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

[4] «Fielding discussing the definition of the REST term». groups.yahoo.com. Consultado em 8 de agosto de 2017

[5] Fielding, Roy; Gettys, Jim; Mogul, Jeffrey; Frystyk, Henrik; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (Junho de 1999). «Hypertext Transfer Protocol -- HTTP/1.1». IETF. Internet Engineering Task Force (IETF). RFC 2616. Consultado em 14 de fevereiro de 2018

[Fielding-Ch6-6] 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.

[7] Accidentally RESTful (em inglês)

[1]

[2]

[3]

[4]

[5]

[6]

[7]