rest - 使用超媒体链接时如何处理 REST 资源的更新

Question

我正在使用 REST-ful API，其中的资源相当相互关联。资源相互引用，并且可以创建或删除这些引用。我有点不确定当资源使用超链接互相引用时如何支持将资源关联在一起。

下面是一个包含两个资源 A 和 B 的简单示例。

Resource A:
  name: integer
  list_b: [list of resource B]

Resource B:
  id: integer
  description: String

现在，A 在其文档中不包含 B，而是包含指向它的链接。使用超媒体时，它可能看起来像这样:

Resource A:
{
    id: 1,
    list_b: [
        { id: 1, href: "https://server/api/b/1" },
        { id: 2, href: "https://server/api/b/2" }
    ]
}

如果用户想要添加或删除 A 列表中的 B 引用之一，考虑到超链接的存在，他们该如何操作？我希望用户能够在一次 PUT 操作中更新整个 A 资源，但输出中没有任何内容表明需要 B 的哪个值。对于我来说，用户使用如下内容执行 PUT 是有意义的:

Resource A:
{
    id: 1,
    list_b: [
        { id: 1, href: "https://server/api/b/1" },
        { id: 2, href: "https://server/api/b/2" },
        { id: 3 },
    ]
}

并接收更新的资源(在响应中)，如下所示:

Resource A:
{
    id: 1,
    list_b: [
        { id: 1, href: "https://server/api/b/1" },
        { id: 2, href: "https://server/api/b/2" },
        { id: 3, href: "https://server/api/b/3" }
    ]
}

我担心的是，在更新资源 A 的 list_b 时，用户不一定知道资源中应包含哪些内容。

处理从一种资源到另一种资源的超链接时，创建和更新应如何工作？是否应该允许客户端更新链接的一部分(id)，还是应该要求他们更新链接的两个部分？

注意:我知道另一种方法可能是公开资源 A 的子 URL。它可以将 list_b 公开为可通过 HTTP 操作的资源(允许客户端对列表资源本身使用 POST、PUT 和 DELETE)。但当 A 包含对其他资源类型的多个引用时，这似乎不太合理。每个引用另一个字段的字段都可能需要一个子 URL，如果有 10 多个字段，则该子 URL 很笨重，并且需要多个 HTTP 请求来更新资源。

Answer 1

HATEOAS 在 RESTful 接口(interface)中将资源连接在一起，这里不清楚您所描述的辅助对象作为独立资源是否真正有意义。 HATEOAS 的“AS”部分提醒我们网页在 Web 应用程序中充当“资源”的角色。每个网页实际上都是应用程序状态的交互式表示(本例中的“应用程序”是一个经典的多页面 Web 应用程序)，并且到其他资源的超链接为用户提供了到其他应用程序状态的转换。

RESTful Web API 采用 JavaScript 代码而不是人类作为其客户端，自然是面向数据访问的，因此其资源本身很少采用“应用程序状态”的形式嗯>。在传统的Web应用程序中，您可以绘制状态转换图并清楚地看到状态之间的连接，从而清楚地看到资源之间的连接。在 RESTful API 中，被动数据资源之间的边界更多地是由客户端/服务器交互的效率和其他微妙的力量决定的。

那么这里的辅助对象(“B”)真的需要表示为一流资源吗？是否存在前端将枚举或以其他方式访问它们的情况，而与它们参与的聚合(“A”)无关？

如果答案是“否”，那么它们显然不应该在“A”结构中以超文本方式表示。然而，我认为答案是"is"，并且您也有充分的理由提供您称为独立资源的所有其他附属对象。在这种情况下，无论如何，有一定数量的路由和 Controller 形式的接口(interface)工作是支持所有这些资源所必需的，因为您的应用程序可能提供了一种方法来单独操作它们，或者至少查询它们(通过超链接，例如您示例中的超链接)。

在这种情况下，对表示“B”对象集合(例如“server/api/b”)的路径的 POST 可以在响应的“location” header 值中返回一个 URL，作为创建新资源的 POST应该做的。当您的用户以交互方式将新的“B”添加到网页上属于“A”的列表时，您的前端可以首先发布新的“B”，成功时通过位置 header 取回其 URL。然后，在 PUT 更新的“A”之前，它可以将该链接合并到其“A”对象内的列表表示中。

ID 值有点麻烦，因为您可能会想通过从 URL 文本中提取 ID 值来破坏后端的封装。真正的 HATEOAS 狂热者让他们的 RESTful API 生成模糊的、散列的或其他难以理解的 URL，专门是为了阻止客户端的这种封装破坏。更好的是，新“B”对象的 POST 在其响应正文中返回新“B”对象的完整表示(包括其 ID)，以便客户端可以重构完整对象并从中提取 ID，从而缩小范围与资源本身的耦合，而不是获取资源的 RESTful 接口(interface)的详细信息。