问题描述
基本问题是，每页应该有一个HATEOAS入口点还是整个应用程序应该有一个入口点？
我看到的大多数示例都使用HATEOAS后端实现单个页面，例如使用prev和next链接分页的列表。但是，当应用程序导航到功能完全不同且需要不同入口点的其他页面时，会发生什么情况？一个人如何组织这样的应用程序？
具体示例：我们有一个带有标签导航功能的应用。主页选项卡显示产品目录，因此输入点为/products，它返回产品的页面1和分页链接。但是，现在我单击“订单”选项卡，其中必须显示过去的订单列表。该页面需要一个完全不同的入口点/orders，主页选项卡对此一无所知。实际上，用户可以使用深层链接直接导航到“订单”标签。
如何考虑这个问题？有没有说明这种方法的示例？
解决方法
有几种解决方法。这是两个：
- SPA从uri中获取上下文（例如id），并使用它在API上进行搜索。该API可以描述模板化的链接/操作，以按其ID搜索资源。
- 让服务器决定呈现什么内容，而不是进行客户端路由。
我们正在朝着＃2迈进。如果我们有一个uri，例如：
https://spa.example/https://api.example/foo/bar
我们使用了该uri的路径部分，并点击了API。根据API响应的内容，我们决定渲染什么。这意味着这些端点的大多数路由都委托给服务器，这与HATEOAS更加一致。
在这种情况下，路径部分是整个绝对URI，但我们也支持相对uri，并具有默认的基本uri。因此，在实践中，这两个uri是等效的（对于我们的SPA）：
https://spa.example/https://api.example/foo/bar
https://spa.example/foo/bar
我们开发并使用ketting / react-ketting来完成大部分繁重的工作