HATEOAS é um acrônimo para "Hipermídia como o mecanismo do estado do aplicativo". A que se refere o "Motor do estado do aplicativo" e, em particular - como a "hipermídia" é o mecanismo dele?
Tanto quanto pude entender, o HATEOAS e os padrões associados, como o HAL, tratam da parte de "descoberta" do REST.
A discussão da Primavera sobre o assunto resume-se em:
Com o HATEOAS, a saída facilita a compreensão de como interagir com o serviço sem consultar uma especificação ou outro documento externo.
O que parece estar dizendo é que, quando você executa respostas compatíveis com HATEOAS, usando, por exemplo, JSON compatível com HAL, o cliente não precisa codificar nenhum caminho de recurso, exceto o URL da API raiz.
O que faz todo o sentido, exceto que parece não ter nada a ver com "Application State". Na melhor das hipóteses, é com a Configuração do servidor (IE, se eu alterar a URL de um recurso (Configuração do servidor), um consumidor ainda pode descobrir onde encontrá-lo.
Elaborando um pouco do que pude entender sobre o HATEOAS, existe um trecho da mesma página de descrição. O que se mostra é que a HATEOAS resolveu o problema de descobrir onde estão os recursos. Mas isso não parece estar relacionado ao "Estado do Aplicativo" ....
Uma apresentação JSON simples é tradicionalmente renderizada como:
{
"name" : "Alice"
}
Os dados do cliente estão lá, mas os dados não contêm nada sobre seus links relevantes.
Uma resposta baseada no HATEOAS seria assim:
{
"name": "Alice",
"links": [ {
"rel": "self",
"href": "http://localhost:8080/customer/1"
} ]
}
Essa resposta não apenas possui o nome da pessoa, mas inclui o URL de auto-link em que essa pessoa está localizada.
Respostas:
Um aplicativo Web, RESTful ou não, geralmente não é simplesmente um serviço de dados; expõe vários recursos e fornece algum comportamento, e por isso tem estado; é feita uma distinção entre o estado do recurso (independente do cliente, gerenciado pelo aplicativo) e o estado do aplicativo , que é específico do cliente. Um aplicativo sem estado não armazena o estado do aplicativo (específico do cliente); em vez disso, ele permite que o cliente ser responsável por ela, e fornece uma API que possibilita a transferência (aplicação) volta estado e para trás (assim, " S tate T ransferência" no RE ST) Da perspectiva de um cliente, um aplicativo Web é uma máquina de estado, residindo atrás de uma API que permite a interação, mas parte do estado é fornecida como informação contextual pelos clientes, para complementar solicitações.
Agora, enquanto estudava o REST, você pode ter encontrado algo chamado The Richardson Maturity Model- descreve a "maturidade" de uma API de aplicativo Web (evoluindo ao longo dos anos), mas é útil para nós como um tipo de referência que coloca as coisas em contexto. Nesse modelo, todos os níveis de maturidade, exceto o final, fornecem essencialmente APIs que facilitam RPCs sobre HTTP. Nesse estilo de design de API, o HTTP é usado como um mecanismo de transporte, mas a comunicação real ocorre através de protocolos personalizados, de modo que os sistemas em interação (clientes e aplicativo) dependem das chamadas "informações fora da banda" para se comunicar (neste contexto, isso significa apenas que esses sistemas se comunicam usando algum padrão personalizado, em vez de aproveitar o hipertexto / hipermídia e, por exemplo, o protocolo HTTP existente). Portanto, o que impulsiona a transferência de estado e as transições de estado ("o mecanismo do estado do aplicativo") não é hipermídia neste caso.
O nível de maturidade final apresenta a restrição HATEOAS e somente então a API se torna RESTful. O cliente inicia a interação através do URI inicial; as responde de servidor com uma representação adequada baseada em hipermídia do estado do aplicativo (que pode variar entre dispositivos ou clientes, ou devido a várias condições - portanto, " Re apresentação" no RE ST), que inclui ações de auto-descritivos que permitem que o cliente inicie a próxima transição de estado (então a hipermídia é agora o que suporta e direciona diretamente o estado do aplicativo).
Deixe-me primeiro garantir que estamos na mesma página. Esse não é o estado do cliente (como no estado interno do próprio cliente), mas o estado do aplicativo Web específico para um cliente específico.
O exemplo que você menciona realmente não ilustra bem, mas a lista de links retornados é essencialmente gerada dinamicamente no servidor e representa as transições de estado disponíveis no momento e, como tal, codifica o estado atual do aplicativo (para esse cliente em particular). Observe que você pode optar por transferir outros bits de informações relacionadas ao estado (em ambas as direções) se o seu aplicativo exigir (portanto, você não se limita aos metadados de transição de estado), mas a restrição é nunca lembrar de nenhum dado específico do cliente no servidor, porque isso prejudica a venda. Observe também que esse estado não precisa ser completo (não precisa ser totalmente significativo quando você o olha isoladamente), mas deve ser suficiente para que a parte receptora tome uma decisão e execute a lógica com base nele. e nada mais (então,
O HATEOAS utiliza a interface uniforme (os padrões comuns e os formatos de troca de dados) para dissociar os clientes e servidores, para que no lado do servidor possam embaralhar as coisas por trás do "contrato" definido pelo tipo hipermídia, mas também porque a comunicação baseada em as informações de banda (protocolos personalizados) geralmente não aproveitam a infraestrutura de rede da maneira que o REST pretende fazer. (Veja a discussão abaixo.)
No seu exemplo, o cliente não basearia sua lógica no URI, mas em metadados (ou anotações), como o atributo "rel". Por exemplo, um navegador não se importa com os URIs nos links, ele apenas precisa saber que tipo de link é (um link clicável, um formulário a partir do qual você pode construir um URI, uma referência na folha de estilo etc.)
REST no contexto
Infelizmente, o REST se tornou um chavão, e todo mundo está falando sobre como ser RESTful, mas todo o contexto do REST está ausente, e você não pode entender o estilo arquitetônico do REST sem entender esse contexto (qual é o problema que o REST realmente é tentando resolver).
REST é uma generalização da arquitetura por trás da Web . Para a maioria de nós, a Web é uma plataforma. Mas para as pessoas que desenvolveram o REST, o WWW é um aplicativo que possui um certo conjunto de requisitos, executando em uma rede mundial. Portanto, o REST é destinado a sistemas que são como a Web em alguns aspectos importantes, que precisam satisfazer um determinado conjunto de propriedades.
Estes são sistemas de rede em larga escala que têm vida longa (pense em décadas). São sistemas que abrangem os limites organizacionais (por exemplo, empresas colaboradoras) ou entre diferentes subentidades de uma grande organização (como diferentes divisões e até equipes). Embora exista colaboração, todas as entidades envolvidas operam amplamente (trabalham, desenvolvem e implantam software) em seus próprios termos, em seu próprio ritmo, com suas próprias preocupações de segurança, e todas elas usam diferentes dispositivos, sistemas operacionais etc. precisam acessar e compartilhar referências aos recursos uns dos outros (documentos, serviços, dados), ao mesmo tempo em que podem evoluir de forma independente e incremental, sem precisar fazer uma coordenação extensa (diabos, é difícil levar as pessoas a fazer uma implantação coordenada mesmo dentro da mesma organização).
Aqueles que prestam serviços precisam ser capazes de fazer coisas como evoluir versões de serviço, adicionar nós ou embaralhar dados com um efeito mínimo nos clientes. Eles precisam escalar. Os clientes (que podem ser serviços) precisam continuar trabalhando, apesar de toda essa atividade no lado do servidor. É provável que os sistemas sejam usados de maneiras imprevistas no futuro. Os recursos que eles acessam e trocam podem ser de vários tipos diferentes e realizados (codificados, digitados, representados, estruturados) internamente (pelos provedores de serviços) de várias maneiras diferentes, mas mesmo assim, para o sistema / rede geral, uma maneira consistente de é necessário acessar recursos e estruturar dados e respostas (interface uniforme).
O REST leva tudo isso em consideração e leva muito em consideração as propriedades da rede. Destina-se a atender às necessidades de aplicativos que são, em um nível alto (dentro de seu próprio domínio comercial), semelhantes em termos de requisitos e restrições ao descrito acima (ou aspiram a ser).
E sim, mas não é uma panacéia. Existem custos e compensações. Ele impõe um certo estilo de comunicação e há um impacto no desempenho. Você está sempre transferindo dados de maneira grosseira, geralmente os mesmos dados repetidamente, em um formato generalizado (e, portanto, pode não ser o mais eficiente para o seu serviço), com vários metadados, geralmente em nós de rede intermediários ( assim, todo o armazenamento em cache na Web - minimiza o envio de dados, mantendo o cliente afastado do serviço, quando possível). O desempenho percebido pelo usuário é importante, o que afeta a forma como você escreve clientes (é por isso que os navegadores começam a renderizar a página antes que tudo esteja baixado ou pronto). Felizmente, você paga esse custo para poder construir um sistema com as propriedades descritas acima.
Por outro lado, se você estiver construindo um sistema com requisitos / restrições diferentes, o custo pode não valer a pena.
fonte
Se você deseja entender REST ou HATEOAS, provavelmente deve começar entendendo a Web . HAL é (efetivamente) apenas um substituto para HTML; se você entender como o HTML "funciona", entender a função do HAL é muito mais fácil.
Capítulo 5 da Tese de Fielding .
Considere como a pesquisa do Google funciona: você usa um marcador para atualizar sua cópia em cache local do formulário de pesquisa, carregar o formulário, digitar sua consulta no formulário, enviá-la e ler os resultados. Nada disso precisava de nenhum recurso do Google incorporado ao cliente - tudo isso usa recursos de HTML; os metadados incluídos no formulário informando ao navegador (por meio de regras de processamento padronizadas) como construir uma solicitação HTTP que retornará uma representação do recurso em repouso (também conhecido como resultados da pesquisa).
O HAL desempenha o mesmo papel - um cliente que reconhece o HAL pode aplicar as regras de processamento para descobrir links nas representações e fazer coisas inteligentes com esses links. Um cliente com reconhecimento de JSON não pode, porque não há nada no modelo de processamento JSON que define um link.
fonte