O que é REST?

Compartilhe nas redes sociais

REST é um acrônimo em inglês para REpresentational State Transfer. É um estilo arquitetural para sistemas de hipermídia distribuídos e foi apresentado pela primeira vez por Roy Fielding em 2000 em sua famosa dissertação.

Como qualquer outro estilo de arquitetura, o REST também tem suas próprias 6 restrições de orientação que devem ser satisfeitas se uma interface precisar ser referida como RESTful. Esses princípios estão listados abaixo.

Princípios Básicos do REST

  1. Cliente-servidor – Ao separar as questões da interface do usuário das questões de armazenamento de dados, melhoramos a portabilidade da interface do usuário em várias plataformas e melhoramos a escalabilidade simplificando os componentes do servidor.
  2. Sem estado – Cada solicitação do cliente para o servidor deve conter todas as informações necessárias para entender a solicitação e não pode tirar proveito de nenhum contexto armazenado no servidor. O estado da sessão é, portanto, mantido inteiramente no cliente.
  3. Armazenável em cache – As restrições de cache exigem que os dados em uma resposta a uma solicitação sejam rotulados implícita ou explicitamente como armazenáveis ou não armazenáveis em cache. Se uma resposta puder ser armazenada em cache, o cache do cliente terá o direito de reutilizar os dados de resposta para solicitações equivalentes posteriores.
  4. Interface uniforme – Ao aplicar o princípio da engenharia de software chamado generalidade à interface do componente, a arquitetura geral do sistema é simplificada e a visibilidade das interações é aprimorada. Para obter uma interface uniforme, várias restrições arquitetônicas são necessárias para orientar o comportamento dos componentes. REST é definido por quatro restrições de interface: identificação de recursos; manipulação de recursos por meio de representações; mensagens autodescritivas; e, hipermídia como o motor de estado do aplicativo.
  5. Sistema em camadas – O estilo do sistema em camadas permite que uma arquitetura seja composta de camadas hierárquicas, restringindo o comportamento do componente de modo que cada componente não possa “ver” além da camada imediata com a qual estão interagindo.
  6. Código sob demanda (opcional) – O REST permite que a funcionalidade do cliente seja estendida por meio do download e da execução de código na forma de applets ou scripts. Isso simplifica os clientes, reduzindo o número de recursos necessários para serem pré-implementados.

Se sua aplicação fere algum desses princípios orientadores do REST, você não a pode chamar de RESTful.

Recurso (resource)

A principal abstração de informações no REST é um recurso. Qualquer informação que possa ser nomeada pode ser um recurso: um documento ou imagem, um serviço temporal, uma coleção de outros recursos, um objeto não virtual (por exemplo, uma pessoa) e assim por diante. REST usa um identificador de recurso para identificar o recurso particular envolvido em uma interação entre componentes.

O estado do recurso em qualquer timestamp específico é conhecido como representação de recurso. Uma representação consiste em dados, metadados que descrevem os dados e links para hipermídia que podem ajudar os clientes na transição para o próximo estado desejado.

O formato de dados de uma representação é conhecido como tipo de mídia (media type). O tipo de mídia identifica uma especificação que define como uma representação deve ser processada. Uma API verdadeiramente RESTful parece hipertexto. Cada unidade endereçável de informação carrega um endereço, seja explicitamente (por exemplo, atributos de link e id) ou implicitamente (por exemplo, derivado da definição do tipo de mídia e estrutura de representação).

De acordo com Roy Fielding:

Hipertexto (ou hipermídia) significa a apresentação simultânea de informações e controles de tal forma que a informação se torna o recurso por meio do qual o usuário (ou autômato) obtém escolhas e seleciona ações. Lembre-se de que o hipertexto não precisa ser HTML (ou XML ou JSON) em um navegador. As máquinas podem seguir os links quando entendem o formato dos dados e os tipos de relacionamento.

Além disso, as representações de recursos devem ser autodescritivas: o cliente não precisa saber se um recurso é um funcionário ou dispositivo. Ele deve agir com base no tipo de mídia associado ao recurso. Portanto, na prática, você acabará criando muitos tipos de mídia personalizados – normalmente um tipo de mídia associado a um recurso.

Cada tipo de mídia define um modelo de processamento padrão. Por exemplo, HTML define um processo de renderização para hipertexto e o comportamento do navegador em torno de cada elemento. Não tem relação com os métodos de recursos GET / PUT / POST / DELETE / … além do fato de que alguns elementos de tipo de mídia definirão um modelo de processo que funciona como “elementos âncora com um atributo href criam um link de hipertexto que, quando selecionado, invoca uma solicitação de recuperação (GET) no URI correspondente ao atributo href codificado por CDATA.”

Métodos de Recursos

Outra coisa importante associada ao REST são os métodos de recursos a serem usados para realizar a transição desejada. Um grande número de pessoas relaciona incorretamente os métodos de recursos aos métodos HTTP GET / PUT / POST / DELETE.

Roy Fielding nunca mencionou nenhuma recomendação sobre qual método ser usado em qual condição. Tudo o que ele enfatiza é que deve haver interface uniforme. Se você decidir que o HTTP POST será usado para atualizar um recurso – em vez de a maioria das pessoas recomendar o HTTP PUT – está tudo bem e a interface do aplicativo será RESTful.

Idealmente, tudo o que é necessário para alterar o estado do recurso deve fazer parte da resposta da API para esse recurso – incluindo métodos e em que estado eles deixarão a representação.

Uma API REST deve ser inserida sem nenhum conhecimento prévio além do URI inicial (marcador) e conjunto de tipos de mídia padronizados que são apropriados para o público-alvo (ou seja, espera-se que seja entendida por qualquer cliente que possa usar a API). A partir desse ponto, todas as transições de estado do aplicativo devem ser orientadas pela seleção do cliente de opções fornecidas pelo servidor que estão presentes nas representações recebidas ou implícitas pela manipulação do usuário dessas representações. As transições podem ser determinadas (ou limitadas) pelo conhecimento do cliente sobre os tipos de mídia e os mecanismos de comunicação de recursos, os quais podem ser aprimorados instantaneamente (por exemplo, código sob demanda).
[A falha aqui implica que a informação fora da banda está conduzindo a interação em vez do hipertexto.]

Outra coisa que o ajudará na construção de APIs RESTful é que os resultados da API baseada em consulta devem ser representados por uma lista de links com informações resumidas , não por matrizes de representações de recursos originais, porque a consulta não é um substituto para a identificação de recursos.

REST e HTTP não são iguais!!

Muitas pessoas preferem comparar HTTP com REST. REST e HTTP não são iguais.

REST != HTTP

Porém, como o REST também pretende tornar a web (internet) mais simples e padronizada, ele defende o uso dos princípios do REST de forma mais estrita. E é aí que as pessoas tentam começar a comparar REST com web (HTTP). Roy Fielding, em sua dissertação, em nenhum lugar mencionou qualquer diretiva de implementação – incluindo qualquer preferência de protocolo e HTTP.

Em palavras mais simples, no estilo de arquitetura REST, os dados e a funcionalidade são considerados recursos e são acessados usando Uniform Resource Identifiers (URIs). Os recursos são acionados por meio de um conjunto de operações simples e bem definidas. Os clientes e servidores trocam representações de recursos usando uma interface e protocolo padronizados – normalmente HTTP.

Os recursos são desacoplados de sua representação para que seu conteúdo possa ser acessado em uma variedade de formatos, como HTML, XML, texto simples, PDF, JPEG, JSON e outros. Os metadados sobre o recurso estão disponíveis e são usados, por exemplo, para controlar o cache, detectar erros de transmissão, negociar o formato de representação apropriado e realizar autenticação ou controle de acesso. E o mais importante, toda interação com um recurso não tem estado.

Todos esses princípios ajudam os aplicativos RESTful a serem simples, leves e rápidos.