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

Question

我已经很高兴第一次尝试使用适合于Web应用程序的HATEOAS，因为用户可以在“节点”树中导航。

每次用户单击一个节点的链接时，服务器都会返回该节点的数据以及服务器 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