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

Question

我们正在寻找关于在由HATEOAS REST API支持的Web应用程序中处理URL(以及与每个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？因为现在我们有某种混合方法,感觉不完全正确.

提前致谢.

问候,

吕克

Answer 1

这是一个艰难的设置。粗略地说，您希望在 API 中添加书签，而 RESTful 系统在某种程度上不鼓励添加书签。

一种可能的解决方案是“书签服务”，它返回当前资源的书签（类似于 bit.ly）url，保证向前兼容，因为当您可能更改规范的 url 结构时，书签服务始终可以转换该位.ly 就像 url 变成规范 url 一样。听起来很复杂，但我们一直看到这种情况，我们称它们为 SEO url，例如：/product-name/ 今天映射到 products/，但明天可能是 /catalog/old-products/。

如何将其与显示 2 个资源的 UI 相匹配，第一个是类似资源的摘要列表，第二个是特定资源，这确实很棘手。我希望这样的页面能够知道其 url 中显示的内容的状态（可能在片段中）。因此，由于它[可能]是处理此类命令的控制器，因此它可能需要两者（列表资源和扩展资源）作为输入。我敢打赌网址会类似于：

list=http://path/to/list/results&expand=http://self/link/of/path

所以最后一部分就是确保它能够继续下去。这又是书签问题。如果您不想构建书签服务，我可能建议您考虑拥有此类书签，您需要将人们转移到新的 URL。当向http://path/to/list/results发出请求并且您想要切换该请求时，您应该将其 301 重定向到新的规范 url，并且应用程序应该更新书签。此类重定向可以包含 &flag=deprecate_message 参数，以触发 UI 中显示客户端的书签已旧且应更换。或者，可以在内部转发响应，并将弃用标记和规范（或最新）链接包含在对旧 URL 的响应中。这会导致阶段性转变。

总之：我还没有看到 HATEOAS 成为向后和向前兼容性的灵丹妙药，但它比现有技术要好得多。也就是说，您仍然必须在 API v1 中决定您希望用户如何迁移到 v2。