Não compreendo o benefício do HATEOAS para APIs destinadas ao uso por programas (em oposição a seres humanos que navegam diretamente na API). Claro, o cliente não está vinculado a um esquema de URL, mas a um esquema de dados que é a mesma coisa em minha mente.
Por exemplo, suponha que eu queira visualizar um item em um pedido, suponha que eu já tenha descoberto ou saiba o URL do pedido.
HATEOAS:
order = get(orderURL);
item = get(order.itemURL[5]);
não HATEOAS:
order = get(orderURL);
item = get(getItemURL(order,5));
No primeiro modelo, eu tenho que saber o fato de que o objeto order possui um campo itemURL. No segundo modelo, eu tenho que saber como construir uma URL de item. Nos dois casos, tenho que "saber" alguma coisa com antecedência, então o que a HATEOAS está realmente fazendo por mim?
web-development
rest
Ritmo
fonte
fonte
get(orderURL);deveria estar lhe dizendothe fact that the order object has an itemURL field.Respostas:
Uma diferença é que o esquema é esperançosamente um padrão, ou pelo menos pode ser reutilizado por outros.
Por exemplo, digamos que você esteja usando a API do Twitter e também queira dar suporte ao StatusNet (ou melhor). Como eles usam o mesmo modelo de dados do Twitter, se a API seguir o HATEOAS, você precisará alterar o URL principal. Caso contrário, agora você precisa alterar cada URL único do código.
Obviamente, se você precisar alterar o código para inserir o URL do ponto de entrada do serviço, pode não parecer tão útil. Realmente brilha é se esse URL é inserido dinamicamente; por exemplo, se você estivesse criando um serviço como o Twillio, que interagisse com a própria API do usuário.
fonte
API explorável: pode parecer trivial, mas não subestima o poder de uma API explorável. A capacidade de navegar pelos dados facilita muito a criação de um modelo mental da API e de suas estruturas de dados para os desenvolvedores do cliente.
Documentação embutida: o uso de URLs como relações de link pode direcionar os desenvolvedores do cliente para a documentação.
Lógica simples do cliente: um cliente que simplesmente segue URLs, em vez de construí-los, deve ser mais fácil de implementar e manter.
O servidor assume a propriedade das estruturas de URL: O uso da hipermídia remove o conhecimento codificado do cliente sobre as estruturas de URL usadas pelo servidor.
Descarga de conteúdo para outros serviços: A Hipermídia é necessária ao descarregar conteúdo para outros servidores (uma CDN, por exemplo).
Controle de versão com links: o Hypermedia ajuda a versão de APIs.
Várias implementações do mesmo serviço: A hipermídia é uma necessidade quando existem várias implementações do mesmo serviço (e um cliente precisa acessar mais de uma).
Você pode encontrar uma explicação detalhada desses tópicos aqui: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html
fonte