URL 在超媒体 (HATEOAS) 驱动的 AngularJS 应用程序中处理
URL handling in a Hypermedia (HATEOAS) driven AngularJS application
我们正在寻找一些关于在 HATEOAS REST API 支持的 Web 应用程序中处理 URLs（以及与每个 URL 相关的状态）的建议，更具体地说
- 如何避免 Web 应用程序 URLs 与 REST API URLs
- 如何在单个视图中处理多个资源
但让我先提供更多背景信息：
我们正在使用超媒体约束在 REST 层之上构建一个 Angular Web 应用程序。 （注意：我更喜欢简单地使用术语 'Hypermedia (constraint)' 而不是 HATEOAS）。
根据超媒体约束的规定，应用程序中任何时间点的可用操作和链接均由 REST API 提供。因此，Web 应用程序不应包含 REST API 的任何硬编码 url，'root' 除外（假设该概念确实存在于 REST API 中）。
另一方面，Web 应用程序中的每个页面都需要添加书签。所以我们不能创建一个 black-box 应用程序（只有一个 url 并且在 SPA 中处理所有状态更改而不更改 URL）。这意味着 Web 应用程序也有它的 URL space，它需要以某种方式映射到 REST API URL space。这已经与超媒体思想发生冲突了。
在 Angular 应用程序中，我们使用 UI 路由器来处理应用程序状态。这是我们如何让它工作的：
- 我们只定义状态，没有URLS
- 我们定义了一个 $urlRouterProvider.otherwise 处理程序，它将当前的 Web 应用程序 URL 映射到相应的 REST API URL，检索相应资源的表示使用该 REST URL 并将其传递给控制器（在 $stateParams 中）。
- 控制器然后可以使用表示中的数据（以及链接和操作），就像它自己进行 REST 调用（或通过服务）一样
到目前为止还不错（或不太好），因为这种方法有一些缺点：
- Web应用URL映射到RESTAPIURL，所以URLspace是耦合的，与使用超媒体约束的基本假设之一：我们无法在不更改 Web 应用程序的情况下更改 REST API URL。
- 在 $urlRouterProvider.otherwise 处理程序中，我们检索当前网络应用程序的表示 URL。但在某些情况下，我们在单个视图中有两个资源（使用 UI 路由器嵌套状态）：例如项目列表和单个项目的详细信息。但是只有一个 URL，因此只检索了项目详细信息的表示，项目列表仍为空。
因此，我们很想听听一些关于如何改进我们处理两个 URL space 的方法的建议。有没有更好的方法让 REST API 决定 Web 应用程序的（可用）行为并且在 Web 应用程序中仍然有可收藏的 URLs？因为现在我们有某种感觉不完全正确的混合方法。
提前致谢。
此致，
吕克
这是一个艰难的设置。粗略地说，您希望在 API 中添加书签，而 RESTful 系统在某种程度上不鼓励添加书签。
一个可能的解决方案是 "bookmark service" returns 书签（bit.ly 类似）url 用于当前资源，保证向前兼容，因为由于您可能会更改规范的 url 结构，书签服务始终可以将 bit.ly（如 url）转换为规范的 url。听起来很复杂，但我们经常看到这一点，我们称它们为 SEO urls 例如：/product-name/ 今天映射到 products/，但明天可能是 /catalog/old-products/。
如何将其与显示 2 个资源的 UI 相匹配，第一个是类似资源的摘要列表，第二个是特定资源，这真的很棘手。我希望这样的页面知道包含它在 url 中显示的内容的状态（可能在片段中）。因此，由于它 [可能] 是处理此类命令的控制器，因此它可能需要（列表资源和扩展资源）作为输入。我打赌 url 看起来像：
list=http://path/to/list/results&expand=http://self/link/of/path
因此，您要做的最后一部分是确保一切正常进行。这又是书签问题。如果您不想构建书签服务，我的建议是，如果您想拥有这样的书签，您需要将人们转移到新的 URLs。当向 http://path/to/list/results 发出请求并且您想切换它时，您应该 301 将它们重定向到新的规范 url 并且应用程序应该更新书签。这样的重定向可以包含 &flag=deprecate_message 参数来触发 UI 中的演示，客户端的书签是旧的，应该被替换。或者，可以在内部转发响应，并将弃用标志和规范（或最新）link 包含在对旧 URL 的响应中。这会导致分阶段过渡。
总而言之：我还没有看到 HATEOAS 可以解决所有向后和向前兼容性问题，但它比现有技术要好得多。也就是说，您仍然必须在 API 的 v1 中就您希望用户如何迁移到 v2 做出决定。
我们正在寻找一些关于在 HATEOAS REST API 支持的 Web 应用程序中处理 URLs（以及与每个 URL 相关的状态）的建议，更具体地说
- 如何避免 Web 应用程序 URLs 与 REST API URLs
- 如何在单个视图中处理多个资源
但让我先提供更多背景信息：
我们正在使用超媒体约束在 REST 层之上构建一个 Angular Web 应用程序。 （注意：我更喜欢简单地使用术语 'Hypermedia (constraint)' 而不是 HATEOAS）。
根据超媒体约束的规定，应用程序中任何时间点的可用操作和链接均由 REST API 提供。因此，Web 应用程序不应包含 REST API 的任何硬编码 url，'root' 除外（假设该概念确实存在于 REST API 中）。
另一方面，Web 应用程序中的每个页面都需要添加书签。所以我们不能创建一个 black-box 应用程序（只有一个 url 并且在 SPA 中处理所有状态更改而不更改 URL）。这意味着 Web 应用程序也有它的 URL space，它需要以某种方式映射到 REST API URL space。这已经与超媒体思想发生冲突了。
在 Angular 应用程序中，我们使用 UI 路由器来处理应用程序状态。这是我们如何让它工作的：
- 我们只定义状态，没有URLS
- 我们定义了一个 $urlRouterProvider.otherwise 处理程序，它将当前的 Web 应用程序 URL 映射到相应的 REST API URL，检索相应资源的表示使用该 REST URL 并将其传递给控制器（在 $stateParams 中）。
- 控制器然后可以使用表示中的数据（以及链接和操作），就像它自己进行 REST 调用（或通过服务）一样
到目前为止还不错（或不太好），因为这种方法有一些缺点：
- Web应用URL映射到RESTAPIURL，所以URLspace是耦合的，与使用超媒体约束的基本假设之一：我们无法在不更改 Web 应用程序的情况下更改 REST API URL。
- 在 $urlRouterProvider.otherwise 处理程序中，我们检索当前网络应用程序的表示 URL。但在某些情况下，我们在单个视图中有两个资源（使用 UI 路由器嵌套状态）：例如项目列表和单个项目的详细信息。但是只有一个 URL，因此只检索了项目详细信息的表示，项目列表仍为空。
因此，我们很想听听一些关于如何改进我们处理两个 URL space 的方法的建议。有没有更好的方法让 REST API 决定 Web 应用程序的（可用）行为并且在 Web 应用程序中仍然有可收藏的 URLs？因为现在我们有某种感觉不完全正确的混合方法。
提前致谢。
此致，
吕克
这是一个艰难的设置。粗略地说，您希望在 API 中添加书签，而 RESTful 系统在某种程度上不鼓励添加书签。
一个可能的解决方案是 "bookmark service" returns 书签（bit.ly 类似）url 用于当前资源，保证向前兼容，因为由于您可能会更改规范的 url 结构，书签服务始终可以将 bit.ly（如 url）转换为规范的 url。听起来很复杂，但我们经常看到这一点，我们称它们为 SEO urls 例如：/product-name/ 今天映射到 products/，但明天可能是 /catalog/old-products/。
如何将其与显示 2 个资源的 UI 相匹配，第一个是类似资源的摘要列表，第二个是特定资源，这真的很棘手。我希望这样的页面知道包含它在 url 中显示的内容的状态（可能在片段中）。因此，由于它 [可能] 是处理此类命令的控制器，因此它可能需要（列表资源和扩展资源）作为输入。我打赌 url 看起来像：
list=http://path/to/list/results&expand=http://self/link/of/path
因此，您要做的最后一部分是确保一切正常进行。这又是书签问题。如果您不想构建书签服务，我的建议是，如果您想拥有这样的书签，您需要将人们转移到新的 URLs。当向 http://path/to/list/results 发出请求并且您想切换它时，您应该 301 将它们重定向到新的规范 url 并且应用程序应该更新书签。这样的重定向可以包含 &flag=deprecate_message 参数来触发 UI 中的演示，客户端的书签是旧的，应该被替换。或者，可以在内部转发响应，并将弃用标志和规范（或最新）link 包含在对旧 URL 的响应中。这会导致分阶段过渡。
总而言之：我还没有看到 HATEOAS 可以解决所有向后和向前兼容性问题，但它比现有技术要好得多。也就是说，您仍然必须在 API 的 v1 中就您希望用户如何迁移到 v2 做出决定。