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

Question

我们正在寻求一些有关在 HATEOAS REST API 支持的 Web 应用程序中处理 URL(以及与每个 URL 相关的状态)的建议，更具体地说是关于

• 如何避免将网络应用程序 URL 与 REST API URL 耦合
• 如何在单个 View 中处理多个资源

但让我首先提供一些更多背景信息:

我们正在具有超媒体约束的 REST 层之上构建 Angular Web 应用程序。 (注:与 HATEOAS 相比，我更喜欢简单地使用术语“超媒体(约束)”)。

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

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

在 Angular 应用程序中，我们使用 UI Router 来处理应用程序状态。以下是我们如何让它发挥作用:

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

到目前为止还不错(或者不太好)，因为这种方法有一些缺点:

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

因此，我们很乐意听到一些关于如何改进处理两个 URL 空间的方法的建议。是否有更好的方法让 REST API 规定 Web 应用程序的(可用)行为，并且在 Web 应用程序中仍然具有可添加书签的 URL？因为现在我们有某种混合方法，但感觉并不完全正确。

提前致谢。

问候，

吕克

Answer 1

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

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

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


列表=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 成为向后和向前兼容性的 Elixir ，但它比现有技术要好得多。也就是说，您仍然必须在 API v1 中决定您希望用户如何迁移到 v2。