仅针对聚合根更新 RESTful 资源

通常我使用以下资源 URI 方案来构建 RESTful API：

POST /products
PATCH /products/{id}
GET /products
GET /products/{id}
DELETE /products/{id}

产品还可能含有产品特点。当我想要获得某些产品的功能时，我会执行GET /products/{id}/features.

顺便说一句，如果我想向给定产品添加新功能，通常我不会提供如下所示的资源 URI：PATCH /products/{id}/features但我认为features是给定产品的一部分，因此，我更新哪些功能可能包含以下功能：

PATCH /products/{id}

{
    "features": {
         "add": [1, 2, 3]
    }
}

另一方面，如果我想更新某些功能元数据，我不会使用产品资源但我会执行这样的请求：

PATCH /products/features/{id}

{
    title: "Test"
}

就我而言，产品特点与特定产品无关，但它们可以与许多产品相关联。

理想情况下，我应该更新哪些功能拥有给定的产品，发布PATCH请求/products/{id}/features顺便说一句，它使服务器 API 过于复杂，因为您需要单独覆盖所有实体的聚合。

我担心的是，考虑某些给定聚合根的关联是否可以作为实体本身的一部分进行更新。

有关该主题的更多背景信息

归根结底，有人可能会说这样的 API 并不完全是 RESTful，因为我不应该期望使用以下方法从某些给定产品中删除功能：PATCH动词但是DELETE: DELETE /products/{id}/features/{featureId}，这使得从客户端角度使用 API 比使用修补程序更容易DTO.

现在你的架构并不完全干净。一方面，你实施了宁静的思维方式，但另一方面，诸如此类的事情

PATCH /products/{id}

{
    "features": {
         "add": [1, 2, 3]
    }
}

or

PATCH /products/features/{id}

{
    title: "Test"
}

不直观。

对于第一个例子，我建议

PATCH /products/{id}

{
    "features": [
        {
            "id": 1
        },
        {
            "id": 2
        },
        {
            "id": 3
        },
        {
            "id": 4
        }
    ]
}

你在哪里提供all该产品的功能。你不能只定义你自己的元素add，它将给定的功能添加到产品中。更新资源的结构应该与您获得的结构相当GET /products/{id}（我猜你没明白add属性，你是吗？）。

对于第二个，你的网址应该是这样的/product-features/{feature_id}要不就/features/{feature_id}。不要打破模式/products/{product_id} with /products/features/{feature_id}。为什么你要这样想？这是合乎逻辑的——当你GET /products，您不会获得包含所有功能列表的资源

{
    ...
    "features": [
        {
             "id": 1
        },
        ...
    ]
    ...
}

但不是所有产品的列表

{
     [
          {
               ....
               "id": 1,
               "features": ...
          },
          ...
     ]
}

回答你的问题，如果你按照我的建议以一种轻松的方式正确实施它，那么更新产品的功能绝对可以用这种方法。

Edit:

关于 /products/features 或 /product-features 的东西，有吗 对此有何共识？你知道有什么好的来源可以确保它是 不仅仅是品味问题？

我认为这是误导。我希望获得所有产品的所有功能，而不是获得所有可能的功能。但是，说实话，很难找到任何直接讨论这个问题的来源，但是有很多文章，人们不会尝试创建像 /products/features 这样的嵌套资源，而是这样做分别地.

关于修补时添加的东西，这是我发现的最简单的方法 表达我正在添加、更新或删除给定的功能 产品。其实就是一个DTO

如果您想对集合使用某些操作，则有一个标准。看看吧在 REST Api 调用中批量更新集合的最佳实践 and https://www.rfc-editor.org/rfc/rfc6902#appendix-A.2。代替

PATCH /products/{id}

{
    "features": {
         "add": [1, 2, 3]
    }
}

你会发送

PATCH /products/{id}

{
    "op": add, "path": "/features/0", "value": 1,
    "op": add, "path": "/features/0", "value": 2,
    "op": add, "path": "/features/0", "value": 3
}

顺便说一句，请注意，您没有回答我问题中的核心问题。

As 一切都可以被视为子资源，如果产品的功能作为一个集合，是产品的一个属性，并且它被视为启用 POST 的子资源，那么我没有看到任何冲突。如果有人发现它不安全，那么你可以剪开即可操作仅在子资源上。

而且，在这个article作者认可了使用 PATCH 更新子资源的方式确实简化了流程（整篇文章有点争议，但还没有结束我们感兴趣的事情）

另一个解决方案是公开您想要的资源的属性 使其可编辑，并使用 PUT 方法发送更新的值。在里面 下面的示例，暴露了用户 123 的电子邮件属性：

PUT /users/123/email
 
[email protected]

虽然它让事情变得清晰，而且看起来是一个很好的决定方式 暴露什么和不暴露什么，这个解决方案介绍了很多 API 的复杂性（控制器中的更多操作、路由 定义、文档等）。然而，它符合 REST 标准，并且 不错的解决方案，但有一个更好的选择：PATCH