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.