HATEOAS (Hypermedia as the Engine of Application State) é uma constraint arquitetural de aplicações REST. Uma API HATEOAS provê informações que permite navegar entre seus endpoints de forma dinâmica visto que inclui links junto às respostas. Esta capacidade a difere de sistemas baseados em SOA e interfaces dirigidas por WSDL(pronuncia-se uísdou). Com SOA, servidores e clientes usualmente devem acessar uma especificação fixa que pode ser acessada em outro lugar na API, ou em um website, ou as vezes distribuído por email.
Nota: Pronunciar HATEOAS não é fácil e pode variar bastante. Algumas pessoas pronunciam algo como “riteos“, outros como “reitos” ou como “reidôs“. Alguns podem se referir a esse conceito arquitetural por hypermedia-driven system – algo como sistema dirigido por hipermídia.
Exemplos
O código a seguir representa um objeto Cliente.
class Cliente { String nome; }
Uma representação JSON tradicional seria algo como:
{ "nome" : "Leandro" }
Os dados do Cliente estão lá, mas os dados não contém nada de relevante sobre suas conexões. Uma representação baseada em HATEOAS deve ser similar ao JSON abaixo:
{ "nome":"Leandro", "links":[ { "rel":"self", "href":"http://localhost:8080/Cliente/1" } ] }
A resposta não contém somente o nome de uma pessoa, mas inclui uma URL com o endereço de onde as informações dessa pessoa podem ser localizadas.
- rel significa relacionamento. No nosso caso o link autoreferencia a pessoa. Sistemas mais complexos incluem outros tipos de relacionamentos. Por exemplo, uma ordem de compra pode ter um relacionamento com cliente”rel”:”Cliente” vinculando a ordem ao Cliente.
- href é uma URL completa que define um único recurso.
Nota:
Apesar de meus exemplos serem em JSON, XML também é aceito como um formato de resposta padrão. HATEOAS não impõe a exigência à um formato em específico. O seu foco é prover links que possibilite navegar entre os recursos de uma API.
Apesar de nossos exemplos serem bem simples é possível construir relações mais complexas. O HATEOAS, facilita aos desenvolvedores, de aplicações cliente, acessar os recursos de uma API sem precisar definir uma especificação, criar um documento externo ou uma wiki para isso.
Observe o JSON abaixo:
{ "conteudo":[ { "preco":499.00, "descricao":"HD Seagate 2TB", "nome":"HD S2TB", "links":[ { "rel":"self", "href":"http://localhost:8080/produto/1" } ], "atributos":{ "conector":"SATA" } }, { "preco":49.00, "descricao":"Mouse Óptico Dell", "nome":" Mouse", "links":[ { "rel":"self", "href":"http://localhost:8080/produto/3" } ], "atributos":{ "conector":"wireless" } } ], "links":[ { "rel":"produto.consulta", "href":"http://localhost:8080/produto/consulta" } ] }
Não apenas os itens e seus precos mostrados, mas também uma URL para cada recurso, fornecendo informações claras sobre como acessar cada recurso. De acordo com o modelo de maturidade de Richardson, HATEOAS é considerado o ultimo nível do REST. Isto significa que em uma aplicação HATEOAS presume-se que os verbos padrão de uma aplicação REST como GET, POST, PUT e DELETE também são adotados. Sendo que cada um deles, como é mostrado acima, provê ao cliente os links necessários ao acesso à uma informação.
É isso aí continuem ligados no blog e em breve teremos uma postagem bem mão na massa com HATEOAS e o nosso velho conhecido Spring Boot. Bons estudos 😉
Treinamentos relacionados com este post
Boa explicação. Obrigado!
Ótima explicação, muito obrigado.
Excelente explicação. Obrigado!!!
Valeu Karan obrigado
Corrija:
“Os dados do Cliente estam lá, mas os dados não contém nada…”
Para:
“Os dados do Cliente estão lá, mas os dados não contém nada…”
Curti sua explicação. Estava caçando uma definição com exemplos assim.
Valeu!
Como seria para um front end consumir uma api nessa maturdade? Pegando o exemplo acima, eu consulto o cliente Leandro e vem um link com a referencia dele…ai como fazer para acessar esse link no front?