0

通过 RESTful 最佳服务，有 HATEOAS 原则告诉我们，我们不应该允许客户端构建资源 URL-s。如果我们遵循这个原则，就很难共享客户端的当前状态。例如，如果您在服务器上有一个 REST 服务，并且您通过 AJAX 使用单页 javascript 客户端获取数据，那么您将有 2 个 url。一个用于客户端状态，一个用于您从 REST 服务获得的结果。由于 pushState，您只能与使用共享客户端状态...如果有人使用以前共享的 url 运行客户端，那么她的客户端将不知道它应该调用的 REST 服务的 url，因为客户端无法构建URL-s，只需从 REST 服务接收并使用它。

例如：

  • 我浏览http://my.client.com
  • 页面从 中获取根资源http://my.api.com，并返回一个链接
  • 链接包含http://my.api.com/usersurl，带有 rel 用户集合
  • 之后，客户端显示一个带有标签的按钮：userlist
  • 我单击该按钮，客户端从 api 获取数据，并打印用户列表
  • 如果我想与我的女朋友共享用户列表，那么我必须使用 pushState 从客户端更改浏览器 url，例如从http://my.client.com更改为http://my.client.com/users
  • 之后我把那个网址发给我的女朋友
  • 她将其复制粘贴到浏览器地址栏中，然后按 Enter。在那之后，客户说了一个巨大的 wtf，因为 - 就像 John Snow - 它不知道那个 url 意味着什么状态......

这个问题可以解决，如果我们允许客户端GET http://my.api.com/users从 url:构建http://my.client.com/users，但这不会是 RESTful，因为客户端不应该构建 api urls...

如果我想在客户端显示一个嵌套菜单，那就是另一个问题，因为我不想在每个答案中都发送整个菜单树。我可以为每个资源创建一个菜单投影，或者使用 OPTIONS 方法或自定义方法来发送该数据，但这会很麻烦。这可以通过以下rel=up链接来解决 - 从 REST 服务获得 - 串联，但如果我不知道应该从哪里关注，它将无法工作......

谷歌机器人也会出现这个问题......

我怎样才能既解决这个问题又保持在 HATEOAS 原则的范围内？

4

1 回答 1

1

通常我们不想与任何人共享所有这些信息，所以我们不能只导出我们所在的当前页面。

将整个资源存储在客户端然后将其推送到服务器以更改服务器上的状态并没有错。如果您担心您的资源变得太大，尽管您可以将资源分开一点。假设您有一个订单资源，并且需要与一个地址相关联。您不需要将地址放在订单资源中，只需一个指向该地址的链接即可使用。用户可以独立添加或更改该地址。所以你可能有类似的东西

www.myapi.com/users/1234/shippingaddresses/default

并且客户端可以为该资源添加一个新地址。然后在订单资源的正文中，您可以拥有该资源的链接

POST www.myapi.com/users/1234/orders
{
    ...order information...
    "shipping_address": "www.myapi.com/users/1234/shippingaddresses/default"
}

要成为 RESTful，客户端不应构建该 URL，它应该在最近的某个时间由服务器提供，可能是在用户选择要使用的地址时。例如，在上一步中，客户端可能已经请求了所有地址

GET www.myapi.com/users/1234/shippingaddresses

并在下拉列表中将地址列表呈现给用户。

于 2013-11-18T10:31:35.603 回答