Transferência de estado representacional - Representational state transfer

"REST" redireciona aqui. Para outros usos, consulte Rest .

Representational state transfer ( REST ) é um estilo de arquitetura de software que foi criado para guiar o design e o desenvolvimento da arquitetura para a World Wide Web . O REST define um conjunto de restrições de como a arquitetura de um sistema hipermídia distribuído em escala da Internet , como a Web, deve se comportar. O estilo de arquitetura REST enfatiza a escalabilidade das interações entre componentes, interfaces uniformes , implantação independente de componentes e a criação de uma arquitetura em camadas para facilitar o armazenamento de componentes em cache para reduzir a latência percebida pelo usuário , reforçar a segurança e encapsular sistemas legados .

O REST tem sido empregado em toda a indústria de software e é um conjunto amplamente aceito de diretrizes para a criação de APIs da web confiáveis ​​e sem estado . Uma API da web que obedece às restrições REST é informalmente descrita como RESTful . As APIs da web RESTful são normalmente baseadas em métodos HTTP para acessar recursos por meio de parâmetros codificados por URL e o uso de JSON ou XML para transmitir dados.

Os "recursos da Web" foram definidos pela primeira vez na World Wide Web como documentos ou arquivos identificados por seus URLs . Hoje, a definição é muito mais genérica e abstrata e inclui tudo, entidade ou ação que pode ser identificada, nomeada, endereçada, tratada ou executada de qualquer forma na web. Em um serviço da Web RESTful, as solicitações feitas ao URI de um recurso geram uma resposta com uma carga útil formatada em HTML , XML , JSON ou algum outro formato. Por exemplo, a resposta pode confirmar que o estado do recurso foi alterado. A resposta também pode incluir links de hipertexto para recursos relacionados. O protocolo mais comum para essas solicitações e respostas é o HTTP. Ele fornece operações ( métodos HTTP ) como GET, POST, PUT e DELETE. Ao usar um protocolo sem estado e operações padrão, os sistemas RESTful objetivam desempenho rápido, confiabilidade e capacidade de crescimento, reutilizando componentes que podem ser gerenciados e atualizados sem afetar o sistema como um todo, mesmo durante a execução.

O objetivo do REST é aumentar o desempenho, escalabilidade, simplicidade, modificabilidade, visibilidade, portabilidade e confiabilidade. Isso é obtido seguindo os princípios REST, como arquitetura cliente-servidor, ausência de estado, capacidade de armazenamento em cache, uso de um sistema em camadas, suporte para código sob demanda e uso de uma interface uniforme. Esses princípios devem ser seguidos para que o sistema seja classificado.

Etimologia

O termo transferência de estado representacional foi introduzido e definido em 2000 por Roy Fielding em sua tese de doutorado. O termo pretende evocar uma imagem de como um aplicativo da Web bem projetado se comporta: é uma rede de recursos da Web (uma máquina de estado virtual ) onde o usuário avança através do aplicativo selecionando links (por exemplo, http: //www.example .com / articles / 21), resultando na representação do próximo recurso (o próximo estado do aplicativo) sendo transferida para o cliente e renderizada para o usuário.

História

Roy Fielding falando na OSCON 2008

A Web começou a entrar no uso diário em 1993-4, quando sites de uso geral começaram a se tornar disponíveis. Na época, havia apenas uma descrição fragmentada da arquitetura da Web e havia pressão na indústria para concordar com algum padrão para os protocolos de interface da Web. Por exemplo, várias extensões experimentais foram adicionadas ao protocolo de comunicação (HTTP) para suportar proxies , e mais extensões estavam sendo propostas, mas havia a necessidade de uma arquitetura Web formal para avaliar o impacto dessas mudanças.

Juntos, os grupos de trabalho W3C e IETF começaram a trabalhar na criação de descrições formais dos três padrões principais da Web: URI , HTTP e HTML . Roy Fielding esteve envolvido na criação desses padrões (especificamente HTTP 1.0 e 1.1 e URI) e, durante os seis anos seguintes, desenvolveu o estilo de arquitetura REST, testando suas restrições nos padrões de protocolo da Web e usando-o como um meio de definir melhorias arquitetônicas - e para identificar incompatibilidades arquitetônicas. Fielding definiu o REST em sua dissertação de doutorado de 2000 "Estilos arquitetônicos e o projeto de arquiteturas de software baseadas em rede" na UC Irvine .

Para criar o estilo de arquitetura REST, Fielding identificou os requisitos que se aplicam ao criar um aplicativo baseado em rede mundial, como a necessidade de uma barreira de entrada baixa para permitir a adoção global. Ele também pesquisou muitos estilos de arquitetura existentes para aplicativos baseados em rede, identificando quais recursos são compartilhados com outros estilos, como cache e recursos cliente-servidor, e aqueles que são exclusivos do REST, como o conceito de recursos. Fielding estava tentando categorizar a arquitetura existente da implementação atual e identificar quais aspectos deveriam ser considerados centrais para os requisitos comportamentais e de desempenho da web.

Por sua natureza, os estilos de arquitetura são independentes de qualquer implementação específica e, embora o REST tenha sido criado como parte do desenvolvimento dos padrões da Web, a implementação da Web não obedece a todas as restrições do estilo de arquitetura REST. Incompatibilidades podem ocorrer devido à ignorância ou descuido, mas a existência do estilo de arquitetura REST significa que podem ser identificados antes de se tornarem padronizados. Por exemplo, Fielding identificou a incorporação de informações de sessão em URIs como uma violação das restrições de REST, que pode afetar negativamente o armazenamento em cache compartilhado e a escalabilidade do servidor. Os cookies HTTP também violam as restrições REST porque podem ficar fora de sincronia com o estado do aplicativo do navegador, tornando-os não confiáveis; eles também contêm dados opacos que podem ser uma preocupação para a privacidade e segurança .

Conceitos arquitetônicos

Um modelo de relacionamento de entidade dos conceitos expressos no estilo de arquitetura REST.

O estilo de arquitetura REST é projetado para aplicativos baseados em rede, especificamente aplicativos cliente-servidor. Mas mais do que isso, ele é projetado para uso em escala da Internet, de modo que o acoplamento entre o agente do usuário (cliente) e o servidor de origem deve ser o mais leve (flexível) possível para facilitar a adoção em larga escala. Isso é obtido criando uma camada de abstração no servidor, definindo recursos que encapsulam entidades (por exemplo, arquivos) no servidor e, assim, ocultando os detalhes de implementação subjacentes (servidor de arquivos, banco de dados, etc.). Mas a definição é ainda mais geral do que isso: qualquer informação que possa ser nomeada pode ser um recurso: uma imagem, uma consulta de banco de dados, um serviço temporal (por exemplo, “clima de hoje em Londres”) ou mesmo uma coleção de outros recursos. Essa abordagem permite a maior interoperabilidade entre clientes e servidores em um ambiente de longa duração em escala de Internet que cruza os limites organizacionais (confiança).

Os clientes só podem acessar recursos usando URIs . Em outras palavras, o cliente solicita um recurso usando um URI e o servidor responde com uma representação do recurso. A representação de um recurso é outro conceito importante em REST; para garantir que as respostas possam ser interpretadas pelo maior número possível de aplicativos clientes , uma representação do recurso é enviada em formato de hipertexto. Assim, um recurso é manipulado por meio de representações de hipertexto transferidas em mensagens entre os clientes e servidores.

A forte dissociação de cliente e servidor junto com a transferência de informações baseada em texto usando um protocolo de endereçamento uniforme forneceu a base para atender aos requisitos da Web: robustez (escalabilidade anárquica), implantação independente de componentes, transferência de dados de grande granulometria e uma barreira de entrada baixa para leitores de conteúdo, autores de conteúdo e desenvolvedores.

Propriedades arquitetônicas

As restrições do estilo arquitetônico REST afetam as seguintes propriedades arquitetônicas:

  • desempenho nas interações de componentes, que pode ser o fator dominante no desempenho percebido pelo usuário e na eficiência da rede;
  • escalabilidade permitindo o suporte de um grande número de componentes e interações entre os componentes;
  • simplicidade de uma interface uniforme;
  • capacidade de modificação dos componentes para atender às necessidades de mudança (mesmo enquanto o aplicativo está em execução);
  • visibilidade da comunicação entre componentes por agentes de serviço;
  • portabilidade de componentes movendo o código do programa com os dados;
  • confiabilidade na resistência a falhas no nível do sistema na presença de falhas em componentes, conectores ou dados.

Restrições arquitetônicas

O estilo de arquitetura REST define seis restrições de orientação. Quando essas restrições são aplicadas à arquitetura do sistema, ele ganha propriedades não funcionais desejáveis , como desempenho, escalabilidade, simplicidade, modificabilidade, visibilidade, portabilidade e confiabilidade. Um sistema que está em conformidade com algumas ou todas essas restrições é vagamente denominado RESTful.

As restrições REST formais são as seguintes:

Arquitetura cliente-servidor

Veja também: Modelo cliente-servidor

O padrão de design cliente-servidor reforça o princípio da separação de interesses : separar os interesses da interface do usuário dos interesses de armazenamento de dados. A portabilidade da interface do usuário é melhorada. No caso da Web, uma infinidade de navegadores da Web foi desenvolvida para a maioria das plataformas sem a necessidade de conhecimento de qualquer implementação de servidor. A separação também simplifica os componentes do servidor, melhorando a escalabilidade, mas, mais importante, permite que os componentes evoluam de forma independente (escalabilidade anárquica), o que é necessário em um ambiente de escala de Internet que envolve vários domínios organizacionais.

Apatridia

Veja também: Protocolo sem estado

Na computação, um protocolo sem estado é um protocolo de comunicação no qual nenhuma informação da sessão é retida pelo receptor, geralmente um servidor. Os dados relevantes da sessão são enviados ao receptor pelo cliente de tal forma que cada pacote de informações transferido pode ser entendido isoladamente, sem informações de contexto de pacotes anteriores na sessão. Essa propriedade de protocolos sem estado os torna ideais em aplicativos de alto volume, aumentando o desempenho ao remover a carga do servidor causada pela retenção de informações da sessão.

Cacheabilidade

Veja também: Cache da web

Como na World Wide Web, clientes e intermediários podem armazenar respostas em cache. As respostas devem, implícita ou explicitamente, definir-se como armazenáveis ​​ou não armazenáveis ​​em cache para evitar que os clientes forneçam dados obsoletos ou inadequados em resposta a outras solicitações. O cache bem gerenciado elimina parcial ou completamente algumas interações cliente-servidor, melhorando ainda mais a escalabilidade e o desempenho.

Sistema em camadas

Veja também: Sistema em camadas

Normalmente, um cliente não pode dizer se está conectado diretamente ao servidor final ou a um intermediário ao longo do caminho. Se um proxy ou balanceador de carga for colocado entre o cliente e o servidor, isso não afetará suas comunicações e não haverá necessidade de atualizar o código do cliente ou servidor. Os servidores intermediários podem melhorar a escalabilidade do sistema , permitindo o balanceamento de carga e fornecendo caches compartilhados. Além disso, a segurança pode ser adicionada como uma camada sobre os serviços da web, separando a lógica de negócios da lógica de segurança. Adicionar segurança como uma camada separada impõe políticas de segurança . Finalmente, os servidores intermediários podem chamar vários outros servidores para gerar uma resposta ao cliente.

Código sob demanda (opcional)

Consulte também: Scripts do lado do cliente

Os servidores podem estender temporariamente ou personalizar a funcionalidade de um cliente transferindo código executável: por exemplo, componentes compilados como miniaplicativos Java ou scripts do lado do cliente como JavaScript .

Interface uniforme

A restrição de interface uniforme é fundamental para o design de qualquer sistema RESTful. Ele simplifica e desacopla a arquitetura, o que permite que cada parte evolua de forma independente. As quatro restrições para esta interface uniforme são:

  • Identificação de recursos em solicitações - recursos individuais são identificados em solicitações, por exemplo, usando URIs em serviços da Web RESTful. Os próprios recursos são conceitualmente separados das representações que são devolvidas ao cliente. Por exemplo, o servidor pode enviar dados de seu banco de dados como HTML , XML ou JSON - nenhum dos quais é a representação interna do servidor.
  • Manipulação de recursos por meio de representações - Quando um cliente mantém uma representação de um recurso, incluindo quaisquer metadados anexados, ele tem informações suficientes para modificar ou excluir o estado do recurso.
  • Mensagens autodescritivas - cada mensagem inclui informações suficientes para descrever como processar a mensagem. Por exemplo, qual analisador invocar pode ser especificado por um tipo de mídia .
  • Hipermídia como o mecanismo de estado do aplicativo ( HATEOAS ) - Tendo acessado um URI inicial para o aplicativo REST - análogo a um usuário da Web humano acessando a página inicial de um site - um cliente REST deve ser capaz de usar links fornecidos pelo servidor dinamicamente para descobrir todos os recursos disponíveis de que necessita. Conforme o acesso prossegue, o servidor responde com texto que inclui hiperlinks para outros recursos que estão disponíveis no momento. Não há necessidade de o cliente ser codificado com informações sobre a estrutura ou dinâmica do aplicativo.

Modelos de classificação

Vários modelos foram desenvolvidos para ajudar a classificar APIs REST de acordo com sua aderência a vários princípios de design REST, como o Modelo de Maturidade de Richardson .

Aplicado a serviços da web

APIs de serviço da Web que aderem às restrições de arquitetura REST são chamadas de APIs RESTful. APIs RESTful baseadas em HTTP são definidas com os seguintes aspectos:

  • um URI de base , como http://api.example.com/;
  • métodos HTTP padrão (por exemplo, GET, POST, PUT e DELETE);
  • um tipo de mídia que define elementos de dados de transição de estado (por exemplo, Atom, microformatos, aplicativo / vnd.collection + json, etc.). A representação atual informa ao cliente como redigir solicitações de transições para todos os próximos estados de aplicativo disponíveis. Isso pode ser tão simples como um URI ou tão complexo como um miniaplicativo Java.

Semântica de métodos HTTP

A tabela a seguir mostra como os métodos HTTP devem ser usados ​​em APIs HTTP, incluindo as RESTful.

Semântica de métodos HTTP
Método HTTP Descrição
PEGUE Obtenha uma representação do estado do recurso de destino.
PUBLICAR Deixe o recurso de destino processar a representação incluída na solicitação.
POR Crie ou substitua o estado do recurso de destino pelo estado definido pela representação incluída na solicitação.
EXCLUIR Exclua o estado do recurso de destino.

O método GET é seguro , o que significa que aplicá-lo a um recurso não resulta em uma mudança de estado do recurso (semântica somente leitura). Os métodos GET, PUT e DELETE são idempotentes , o que significa que aplicá-los várias vezes a um recurso resulta na mesma mudança de estado do recurso que aplicá-los uma vez, embora a resposta possa ser diferente. Os métodos GET e POST podem ser armazenados em cache , o que significa que as respostas a eles podem ser armazenadas para reutilização futura.

Discussão

Ao contrário dos serviços da web baseados em SOAP , não existe um padrão "oficial" para APIs da web RESTful. Isso ocorre porque REST é um estilo de arquitetura, enquanto SOAP é um protocolo. REST não é um padrão em si, mas as implementações RESTful fazem uso de padrões, como HTTP , URI , JSON e XML . Muitos desenvolvedores descrevem suas APIs como sendo RESTful, embora essas APIs não cumpram todas as restrições arquitetônicas descritas acima (especialmente a restrição de interface uniforme).

Veja também

Referências

Leitura adicional