Question

我第一次很高兴地尝试使用HATEOAS，它使用了一个非常合适的Web应用程序，因为用户可以浏览“节点”树。

每次用户单击指向节点的链接时，服务器都会返回该节点的数据以及相关注释的数据的服务器 URL。

HATEOAS响应正文：

    {"description":"A good node!",
     "category":"IDEAL",
     "placement":"Q16","
     "_links":{"self":{"href":"http://localhost:8081/position?id=393"}},
     "_embedded":{
       "parent":
       {"placement":"root","category":"IDEAL","_links":{"self":{"href":"http://localhost:8081/position?id=384"}}},
      "next_nodes":[
           {"placement":"Q13","category":"GOOD","_links":{"self":{"href":"http://localhost:8081/position?id=362"}}}
           {"placement":"J10","category":"BAD","_links":{"self":{"href":"http://localhost:8081/position?id=365"}}}
       ]}}

当单页Web应用程序客户端显示该节点及其与其他节点的关系的数据时，用户单击以指示遍历到新节点，然后Web App客户端从HATEOAS提供的下一个服务器URL中获取数据。

这提供了HATEOAS的承诺-状态在响应主体中，下一个状态的服务器URL也在响应正文中，因此Web应用程序客户端无需知道除第一个根URL之外的任何信息。

但是，当（显然）用户说“我想要该节点的URL（客户端URL），以便可以返回它”时，这变得很明显。

对于使用HATEOAS的Web应用程序客户端，“当前节点”的唯一可用表示形式是“ _self”链接。实际上是不透明的。

那么您如何将其嵌入到Web客户端路由/链接中以供用户保存并返回？

在上图所示的应用程序中，我发现自己也被迫与Web客户端共享位置ID，然后被迫为该位置重建服务器URL。

这是HATEOAS的预期效果吗？似乎几乎可以完全打破它，但是肯定我缺少一些基本的东西吗？

Answer 1

我过去通过使用以下网址解决了此问题：

https://webapplication.example.org/#http://api.example.org/some/resource

在需要提供应用程序状态链接的地方如何使用HATEOAS（甚至是很实用的做法）？

1 个答案: