rest - 在使用HATEOAS时找到 Restful 资源？

Question

当阅读有关HATEOAS/Hypermedia约束时，我经常看到的一件事是资源应具有某种self/href。
这样做的理由是，客户端不需要知道如何为该特定资源构造网址，例如用于更新资源。

例如

{
     //instead of "id":"123"
     "href":"/api/v1/orders/123",

     order state...
}

我喜欢这个主意。

但是，该概念与获取数据如何匹配？
假设我需要提取具有特定订单ID的订单，那么客户将如何处理呢？
在这种情况下，我仍然需要知道如何构造资源的URL，对吗？

客户应该如何知道在哪里以及如何寻找资源？
它是否必须以某种方式了解API URL？

Answer 1

精心设计的HATEOAS API将具有清晰的入口点，其余的应用程序行为将可从此处发现。

因为问题特别是关于HATEOAS，所以我想说使用URI模板会使客户端承担太多责任。相反，您应该为给定当前应用程序状态的资源上的每个有效操作提供一个显式URL。

这不仅仅是一个风格上的观点。如果服务器提供了模板，则客户端开发人员必须编写代码以填充模板，这将在模板之间创建耦合。现在，您必须先更改与客户端之间的契约(Contract)，才能更改服务器端URL结构。使用HATEOAS，您可以将URL与资源上允许的每个操作相关联，而客户端只关心该操作。 URL实际上是一个不透明的句柄:如Ian Robinson所说，“选择自己的冒险”。

HATEOAS与使用超媒体(包含指向其他媒体的链接的媒体)有关，以使客户端能够在应用程序周围进行导航，而无需了解其最后收到的响应。这意味着每个响应都应为客户端提供代表当前资源上所有有效操作的即用型URL。

请记住，通过有线方式获得的东西仅仅是资源的一种表示形式(REST代表REpresentational State Transfer)。根据您当前的上下文(例如您的当前权限集和当前应用程序状态)，同一资源可以有不同的表示形式。不同的表示形式可以合理地提供不同的后续操作。

使用您的示例，订单的所有者可能会看到以下内容:

{
  "id": "/api/v1/orders/123", // reference to the current resource
  "rel": {
    "cancel": {
      "url": "/api/v1/orders/cancel?order_id=123",
      "method": "POST",
      // Metadata about what the cancel operation returns...
    },
    "list_orders": {
      "url": "/api/v1/orders",
      "method": "GET",
      // Metadata about what the list_orders operation returns...
    },
    // ...
    // Other operations available to the owner
  },
  // ...
  // Order state
}

在这里，我正在定义一个使用键作为操作名称或HATEOAS术语中的关系的映射，尽管我同样可以使用名为 "rel"的键以及 "cancel"和 "list_orders"的值分别获得一个映射列表。

运输协调员说，另一个角色可能看不到 cancel操作，因为他们没有取消订单的权限。