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

14

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 provado neste momento um enorme sistema de hipertexto distribuído bem-sucedido, de modo que esse tipo de validação do REST é uma arquitetura de sucesso para o domínio da hipermídia distribuída principalmente navegada e consumida pelos humanos.

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

Minha preocupação é que o HATEOAS faz 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. Mas 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 for especificamente programado para consumi-los. Retornar uma URL para o cliente não torna o cliente capaz de consumir o recurso indicado.

    
por JacquesB 29.04.2017 / 13:20
fonte

5 respostas

14

AFAIK Fielding didn't claim REST was any good, he was just describing the de-facto architecture of the web.

Isso significa um pouco, eu acho. REST é, afinal, uma enumeração do estilo arquitetônico que Fielding estava usando como arquiteto-chefe do Especificação HTTP / 1.1 .

But is there actually any reason to think REST is a desirable architecture for this domain? Is there any evidence that say HATEOAS is a beneficial design principle for machine-to-machine communication?

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

By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

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 que utilizo para enviar respostas para o stackexchange. Em particular, não importa qual navegador eu estou usando, ou se o meu navegador está algumas atualizações atrás (ou à frente) do que o roteador está esperando. Não importa que a organização de engenharia que escreveu o navegador seja completamente independente da organização que criou a interface do roteador.

apenas funciona .

Não é, obviamente, universal. Fielding, em 2008 , escreveu:

That doesn’t mean that I think everyone should design their own systems according to the REST architectural style. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.

As restrições que formam o estilo arquitetural REST foram escolhidas para as propriedades que elas induzem; Se essas propriedades não forem valiosas para o seu caso de uso, você deve absolutamente considerar a possibilidade de eliminar as restrições correspondentes.

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

schema.org é uma 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 tomadas.

Mas é trabalho; você precisa investir no desenvolvimento de representações amigáveis de seus recursos e garantir que essas representações permaneçam compatíveis e retrocompatíveis, para que os clientes possam ser desenvolvidos independentemente.

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 de arquitetura apropriada.

    
por 29.04.2017 / 16:39
fonte
4

Não, 'REST total' não é tão bom assim.

Como evidenciado pela falta de pessoas que implementam o HATEOS em suas APIs e os intermináveis argumentos sobre qual verbo HTTP usar para uma chamada em particular.

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

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

Então o segundo problema foi XML, o JavaScript não o entendeu, os esquemas eram um saco e você acabaria com enormes arquivos txt consistindo principalmente de <MyLongObjectName> . Então, as pessoas começaram a usar o JSON.

Agora o REST tem um pouco de culto em torno disso, mas como as regras são tão vagas, não impede que você crie uma API utilizável, o que é simples o suficiente para que os consumidores "apenas a comprem" e a usem mês no processo de embarque.

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

Mesmo antes de Roy Fielding ter escrito sua dissertação sobre o REST , o HTTP já estava projetado em torno dos princípios que mais tarde se torna conhecido como REST. Na conclusão de sua dissertação , ele escreveu:

At the beginning of our efforts within the Internet Engineering Taskforce to define the existing Hypertext Transfer Protocol (HTTP/1.0) [19] and design the extensions for the new standards of HTTP/1.1 [42] and Uniform Resource Identifiers (URI) [21], I recognized the need for a model of how the World Wide Web should work. This idealized model of the interactions within an overall Web application, referred to as the Representational State Transfer (REST) architectural style, became the foundation for the modern Web architecture, providing the guiding principles by which flaws in the preexisting architecture could be identified and extensions validated prior to deployment.

REST e HATEOS são adequados para o problema para o qual foram projetados:

REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of component implementations. This is achieved by placing constraints on connector semantics where other styles have focused on component semantics. REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system.

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

Likewise, proposed extensions can be compared to REST to see if they fit within the architecture; if not, it is more efficient to redirect that functionality to a system running in parallel with a more applicable architectural style.

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

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 ser de longa duração; para esses problemas, as restrições REST são apenas uma camisa de força.

But is there actually any reason to think REST is a desirable architecture for this domain? More specifically, is there any evidence that say HATEOAS is a beneficial design principle for machine-to-machine communication?

A evidência é o sucesso da Web na solução de 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 possuem todos os requisitos da Web e não precisam obedecer a todas as restrições do REST para um bom desempenho. É por isso que existem muitas arquiteturas de sucesso que funcionam bem apenas aplicando algumas partes do REST, mas não as outras. HATEOAS e Uniform Interface, por exemplo, são princípios que muitas vezes são ignorados por APIs que não precisam cruzar limites organizacionais e sistemas que têm um período de suspensão relativamente curto.

    
por 30.04.2017 / 15:00
fonte
2

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

REST is NOT an architecture!

Resto é um estilo arquitetônico, que é a abstração de diferentes arquiteturas que existem na internet.

REST is an accumulation of design constraints to induce architectural properties

REST é uma palavra de ordem e todos desejam ter a API RESTful. Na realidade, quando as pessoas enfrentavam restrições de REST, elas descartavam algumas dessas restrições porque não havia necessidade ou benefício para elas aplicarem todas as restrições.

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

REST na AEM

    
por 24.05.2017 / 18:16
fonte
0

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

    
por 02.05.2017 / 02:51
fonte

Tags