超媒体(HATEOAS)驱动的AngularJS应用程序中的URL处理

>如何避免将Web应用程序URL与REST API URL相结合
>如何在单个视图中处理多个资源

但是,首先让我提供更多背景信息：

我们正在使用超媒体约束的REST层之上构建一个Angular Web应用程序. (注意：我更喜欢在HATEOAS上使用术语’超媒体(约束)’).

根据超媒体约束的规定,REST API会在任何时间点提供应用程序中的可用操作和链接.因此,Web应用程序不应包含REST API的任何硬编码URL,除了“root”(假设概念确实存在于REST API中).

另一方面,Web应用程序中的每个页面都需要是可收藏的.因此,我们无法创建一个黑盒应用程序(使用单个URL并在SPA中处理所有状态更改而不更改URL).这意味着Web应用程序还具有其URL空间,该空间需要以某种方式映射到REST API URL空间.这已经与超媒体理念发生冲突.

在Angular应用程序中,我们使用UI路由器来处理应用程序状态.以下是我们如何运作：

>我们只定义状态,没有URL
>我们定义了一个$urlRouterProvider.otherwise处理程序,它将当前Web应用程序URL映射到相应的REST API URL,检索与该REST URL对应的资源的表示形式,并将其传递给控制器??(在$stateParams中).
>然后,控制器可以使用表示中的数据(以及链接和操作),就像它本身(或通过服务)进行REST调用一样

到目前为止这么好(或不是真的),因为这种方法有一些缺点：

> Web应用程序URL映射到REST API URL,因此两个URL空间都是耦合的,这与使用超媒体约束的基本假设之一相冲突：我们无法在不更改Web应用程序的情况下更改REST API URL.
>在$urlRouterProvider.otherwise处理程序中,我们检索当前Web应用程序URL的表示形式.但在某些情况下,我们在单个视图中有两个资源(使用UI路由器嵌套状态)：例如项目列表和单个项目的详细信息.但是只有一个URL,因此只检索项目详细信息的表示,并且项目列表保持为空.

因此,我们希望听到一些关于我们如何改进处理两个URL空间的方法的建议.是否有更好的方法使REST API指示Web应用程序的(可用)行为,并且仍然在Web应用程序中具有可收藏的URL？因为现在我们有某种混合方法,感觉不完全正确.

提前致谢.

问候,

吕克