HATEOAS vs GUI do aplicativo Frontend

4

Acabei de encontrar HATEOAS . Acho que entendo o que significa, mas algo não está claro para mim.

Não há nenhum lugar para ser encontrado como posso criar o cliente consumidor em HTML. Eu posso imaginar que para alguns links eu vou gerar botões, para outros haverá hyperlinks. Isso pode ser feito até agora.

Mas como criar a GUI para ser independente. Quero dizer

  • como criar as páginas da GUI de maneira genérica (o layout não pode fazer parte da API)
  • como descrever os dados, ou seja, a definição do formulário, o conteúdo da tabela, o cliente não saberá como os dados se parecem (para HTML, é um ser humano razoável pode interpretá-los corretamente)
  • como limitar os dados (o usuário não pode acessar alguns campos)

Espero que ainda tenha muita lógica no front end. É possível criar um front end genérico + bonito?

    
por Zveratko 14.04.2015 / 15:39
fonte

1 resposta

0

O ponto principal é que o cliente não sabe nada sobre os detalhes além do ponto de entrada.

Em vez de assar a API no cliente, o cliente busca o documento no ponto de entrada e usa os tipos de recursos retornados para navegar pelos resultados.

Com um site, o navegador já faz isso e a única parte diferente é o servidor, não o cliente. A questão nesse caso é que o servidor não tem a API integrada, mas constrói as URLs com base nos tipos de dados e, quando você faz uma solicitação em vez de rotear com base na URL, ela olha para os tipos de dados. e usa-os para descobrir o que está sendo solicitado.

Então, quando você está construindo um cliente GUI personalizado, tudo o que você precisa fazer é teimosamente se recusar a inserir qualquer informação sobre a estrutura da URL. Então você não tem escolha a não ser fazer um pedido ao URL do ponto de entrada, analisar os tipos de dados retornados, usar esses tipos para decidir qual objeto usar e, em seguida, extrair o URL do objeto.

Normalmente, para um cliente que não seja um navegador da web, significa que você está passando por uma árvore XML e ignora totalmente onde está a árvore; você está apenas olhando para os atributos de tipo adicionados. Você sabe onde você está pelos tipos de objeto em cada nível. Por exemplo, você solicita um documento de nível superior e deseja editar o perfil do usuário, em vez de pesquisar um caminho com base em uma API, você procura o tipo. Você tem que assar os tipos no cliente, em vez dos caminhos da API. E então o nó com o tipo de perfil irá conter um URL para seguir. Então o formulário também tem um tipo. Portanto, mesmo que haja dois formulários e seu cliente saiba apenas sobre um deles, ele ainda preenche o correto.

Limitar os campos que o usuário pode acessar não deve ser afetado por HATEOAS.

Nem o servidor nem o cliente "sabem" (ou se preocupam com) o layout da URL. Você só usa informações de tipo adicionadas.

Você precisará aprofundar os detalhes da implementação antes que isso faça muito sentido.

O

link explica detalhadamente com exemplos.

    
por 02.01.2019 / 21:23
fonte

Tags