REST

A REST (Relação de Serviços de Terceiros) deve ser preenchida por todos os inscritos no Cadastro de Atividades Econômicas, com a finalidade de relacionar os Prestadores de Serviços contratadosmensalmente

A Transferência de Estado Representativo (Representational State Transfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídia distribuídos como a [[Internet|World Wide Wnta 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 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 acord 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

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 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 muito debate, sem a distinção entre recursos e suas representações é demasiado utópica 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 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 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.

REST e RPC

Uma aplicação web REST requer um enfoque de desenho diferente a uma aplicação baseada em RPCs. 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 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 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>
 <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 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.

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/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 .
• 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 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".

Ver também

• XML
• Serviços web
• SOAP

Ligações externas

• REST: Uma Arquitectura Web para Serviços Web por Sérgio Nunes e Gabriel David (Arquivo em PDF).