REST e HATEOAS são uma boa arquitetura para serviços da web?

Se bem entendi, o REST foi formalizado por Roy Fielding como um modelo descritivo da arquitetura da web. AFAIK Fielding não alegou que o REST era bom, ele estava apenas descrevendo a arquitetura de fato da web. A web já havia, nesse momento, provado um enorme sistema de hipertexto distribuído com sucesso, portanto esse tipo de validação do REST é uma arquitetura bem-sucedida para o domínio da hipermídia distribuída, principalmente navegada e consumida por seres humanos.

Os serviços da web REST foram criados aplicando a arquitetura REST às APIs. Mas existe realmente alguma razão para pensar que o REST é uma arquitetura desejável para esse domínio? Mais especificamente, há alguma evidência que diga HATEOAS é um princípio de design benéfico para a comunicação máquina a máquina?

Minha preocupação é que o HATEOAS faça sentido para a hipermídia, porque existem poucos tipos de conteúdo conhecidos (HTML, imagens, vídeo etc.) e o cliente sabe como consumi-los. Porém, para APIs, os tipos de conteúdo são muito específicos e só podem ser consumidos de forma significativa pelo cliente se o cliente estiver especificamente programado para consumi-los. O retorno de uma URL ao cliente por si só não permite que o cliente consuma o recurso indicado.

AFAIK Fielding não alegou que o REST era bom, ele estava apenas descrevendo a arquitetura de fato da web.

Isso subestima um pouco, eu acho. Afinal, o REST é uma enumeração do estilo de arquitetura que Fielding estava usando como arquiteto-chefe da especificação HTTP / 1.1 .

Mas existe realmente alguma razão para pensar que o REST é uma arquitetura desejável para esse domínio? Existe alguma evidência que diga HATEOAS é um princípio de projeto benéfico para a comunicação máquina a máquina?

"Depende". HATEOAS faz parte da restrição de interface uniforme do REST.

Ao aplicar o princípio de generalidade da engenharia de software à interface do componente, a arquitetura geral do sistema é simplificada e a visibilidade das interações é aprimorada. As implementações são dissociadas dos serviços que prestam, o que incentiva a capacidade de evolução independente. A desvantagem, no entanto, é que uma interface uniforme degrada a eficiência, uma vez que as informações são transferidas de forma padronizada, e não específica para as necessidades de um aplicativo. A interface REST foi projetada para ser eficiente para a transferência de dados hipermídia de alta granularidade, otimizando para o caso comum da Web, mas resultando em uma interface que não é ideal para outras formas de interação arquitetural.

Então, vamos pensar por um momento sobre o que isso significa. Quando estou tendo problemas com meu roteador sem fio, posso me comunicar com ele usando o mesmo navegador usado para enviar respostas para o stackexchange. Em particular, não importa qual navegador estou usando ou se meu navegador está algumas atualizações atrasado (ou à frente) do que o roteador está esperando. Não importa que a organização de engenharia que criou o navegador seja completamente independente da organização que criou a interface do roteador.

Isso simplesmente funciona .

Naturalmente, não é universal. Fielding, em 2008 , escreveu:

Isso não significa que acho que todos deveriam projetar seus próprios sistemas de acordo com o estilo de arquitetura REST. O REST é destinado a aplicativos baseados em rede de longa duração que abrangem várias organizações. Se você não vê a necessidade das restrições, não as use.

As restrições que formam o estilo arquitetônico REST foram escolhidas para as propriedades que eles induzem; se essas propriedades não forem valiosas para o seu caso de uso, considere a possibilidade de eliminar as restrições correspondentes.

Onde máquina para máquina fica difícil, é que você perdeu a capacidade do ser humano de combinar com a semântica fornecida pelas representações. Os clientes podem entender apenas os tipos de mídia, mas normalmente temos um ser humano observando as dicas semânticas para obter significado.

O schema.org é parte de um esforço para criar um vocabulário legível por máquina; os agentes da máquina usam o cliente para encontrar as dicas semânticas e aplicam seu próprio entendimento do significado para escolher as ações corretas a serem executadas.

Mas é trabalho; você precisa investir no desenvolvimento de representações amigáveis ​​à máquina de seus recursos e garantir que essas representações permaneçam compatíveis com versões anteriores e anteriores, para que os clientes possam ser desenvolvidos de forma independente.

Quando uma única organização controla o cliente e o servidor, os benefícios dessa independência são muito menores; nesse caso, a restrição pode não ser uma opção arquitetural apropriada.

Não, 'REST completo' não é tão bom.

Como evidenciado pela falta de pessoas que implementam o HATEOS em suas APIs e os argumentos intermináveis ​​sobre os quais o verbo HTTP usar para uma chamada específica.

Mas você precisa reconhecer por que o REST é tão popular. Antes de sua adoção, havia vários protocolos complicados e malucos, como ebXML e SOAP, envolvendo reconhecimentos, tempos limite, IDs de conversação e estado.

Colocar essas coisas em funcionamento e explicá- las aos consumidores da API foi uma tarefa difícil. "por que simplesmente não faço um GET com o ID que eu quero na string de consulta e você me envia os dados?" era uma pergunta óbvia e comum.

Em seguida, o segundo problema era XML, o javascript não entendia, os esquemas eram um pé no saco e você acabaria com enormes arquivos txt compostos principalmente por ele <MyLongObjectName>. Então, as pessoas começaram a usar JSON.

Agora, o REST tem um pouco de culto, mas como as regras são tão vagas, não impede que você crie uma API utilizável que seja simples o suficiente para que os consumidores 'simplesmente entendam' e a usem sem 6 meses de embarque. processo.

É importante notar que Roy não foi o inventor original da maioria dos princípios do REST, ele reúne muitos princípios conhecidos por trabalhar em sistemas anteriores para resolver vários problemas específicos. O REST é simplesmente a conclusão natural de aplicar esses princípios em uma única arquitetura.

Mesmo antes de Roy Fielding escrever sua dissertação sobre o REST , o HTTP já era projetado em torno dos princípios que mais tarde se tornam conhecidos como REST. Na conclusão de sua dissertação , ele escreveu:

No início de nossos esforços no Internet Engineering Taskforce para definir o protocolo de transferência de hipertexto existente (HTTP / 1.0) [19] e projetar as extensões para os novos padrões de HTTP / 1.1 [42] e URI (Uniform Resource Identifiers) [21] ], Reconheci a necessidade de um modelo de como a Internet deveria funcionar. Esse modelo idealizado de interações em um aplicativo Web geral, conhecido como estilo arquitetônico Representational State Transfer (REST), tornou-se a base da arquitetura moderna da Web, fornecendo os princípios orientadores pelos quais falhas na arquitetura preexistente podiam ser identificadas e extensões validado antes da implantação .

REST e HATEOS é um bom ajuste para o problema para o qual foi projetado:

O REST é um conjunto coordenado de restrições arquiteturais que tenta minimizar a latência e a comunicação de rede e, ao mesmo tempo, maximizar a independência e a escalabilidade das implementações de componentes . Isso é obtido colocando restrições na semântica do conector, onde outros estilos se concentram na semântica do componente. O REST permite o armazenamento em cache e a reutilização de interações, a substituibilidade dinâmica de componentes e o processamento de ações por intermediários , atendendo assim às necessidades de um sistema hipermídia distribuído em escala da Internet.

No entanto, deve-se notar que a Web e o REST não são necessariamente adequados para todos os problemas:

Da mesma forma, as extensões propostas podem ser comparadas ao REST para verificar se elas se encaixam na arquitetura; caso contrário, é mais eficiente redirecionar essa funcionalidade para um sistema executando em paralelo com um estilo de arquitetura mais aplicável.

Portanto, se sua pergunta for "REST e HATEOAS é uma boa arquitetura para serviços da web?" então, a resposta é simplesmente "sim, é uma boa arquitetura para serviços da web". O problema realmente é se todos os problemas que as pessoas tentaram resolver, adaptando-os às restrições da Web, deveriam realmente ter sido serviços da Web em primeiro lugar.

Existem muitas APIs que realmente não se encaixam no REST. APIs que não precisam do tipo de escalabilidade que o REST foi projetado para resolver, não são consumidas por várias organizações que podem evoluir de forma independente e não precisam ter vida longa; para esses problemas, as restrições REST são apenas uma camisa de força.

Mas existe realmente alguma razão para pensar que o REST é uma arquitetura desejável para esse domínio? Mais especificamente, há alguma evidência que diga HATEOAS é um princípio de projeto benéfico para a comunicação máquina a máquina?

A evidência é o sucesso da Web em resolver os problemas de muitas pessoas. O REST é uma arquitetura híbrida, que combina os designs de muitos estilos arquitetônicos anteriores. Muitos domínios problemáticos não têm todos os requisitos da Web e não precisam obedecer a todas as restrições do REST para ter um bom desempenho. É por isso que existem muitas arquiteturas bem-sucedidas que funcionam bem aplicando apenas algumas partes do REST, mas não outras. HATEOAS e Uniform Interface, por exemplo, são princípios frequentemente ignorados pelas APIs que não precisam cruzar fronteiras e sistemas organizacionais que possuem um período de reprovação relativamente curto.

Na apresentação de Fielding no Adobe Experience Manager:

O REST não é uma arquitetura!

O resto é um estilo arquitetônico, que é uma abstração de uma arquitetura diferente que existe na Internet.

REST é um acúmulo de restrições de design para induzir propriedades arquitetônicas

REST é um chavão e todo mundo quer ter a API RESTful. Na realidade, quando as pessoas se deparam com restrições REST, elas eliminam algumas dessas restrições porque não há necessidade ou benefício a ser ganho para que elas apliquem todas as restrições.

Como você mencionou, o HATEOAS é útil quando o cliente é um navegador da web. Quando o cliente é um aplicativo móvel, talvez não tanto. Seria uma boa prática, mas também há custos associados ao design de um aplicativo como esse, tanto que, por exemplo, a equipe de aplicativos para dispositivos móveis e a equipe de back-end concordaram em abandonar essa restrição. E isso faz sentido porque as duas equipes não são tão fracamente acopladas porque trabalham para a mesma empresa.

REST no AEM

se o que você deseja é criar um serviço consumido por outro servidor, o xmlrpc é a escolha correta. Se o que você deseja é um serviço para ser consumido por thin clients ou dispositivos de baixo consumo de energia .. ou clientes desconhecidos pela Internet aberta, talvez considere descansar usando json. Mas lembre-se, json é uma notação inferior para especificar dados gerais, quando comparado ao xml.