为嵌套资源设计rest api

问题描述

我的系统中有以下资源 1. 服务 2. 功能具有以下 JSON 结构的功能，

{
 id: "featureName",state: "active",allowList: [serviceID1,serviceID2],denyList: [serviceID3,serviceID4]
}

我正在尝试更新由 serviceID 组成的 allowList 或 denyList 并考虑使用 PATCH 方法来执行如下操作，

/features/{featureId}/allowlist 
/features/{featureId}/denylist 
/features/{featureName}/state/{state}

我的第一个问题是我是否应该在 url 中包含许可名单、状态、拒绝名单，因为我的资源是服务和功能，而不是许可名单或拒绝名单。

rest 端点应该是什么样子的？
阅读下面提到的线程后，我正在考虑如下重组网址，

/features/{featureId}

[
    { "op": "add","path": "/allowList","value": [ "serviceA","serviceB"]},{ "op": "update","path": "/state","value": false}
]

最后，在这里使用 PATCH 是否合理？或者有更好的方法来设计 api。

注意：我从线程 REST design for update/add/delete item from a list of subresources 得到了一些帮助，但不经常使用补丁。

解决方法

rest 端点应该是什么样子的？

用于编辑（PUT、PATCH）资源的 URI 应该与用于读取（GET）资源的 URI 相同。这种设计的动机是cache-invalidation；您成功的写入会自动使之前缓存的相同资源（相同 URI）的读取无效。

最后，在这里使用 PATCH 是否合理？或者有更好的方法来设计 api。

在此示例中，文档的表示与 HTTP 标头相比较小，并且您的补丁文档的大小接近资源表示的大小。如果这是典型情况，我会倾向于使用 PUT 而不是 PATCH。 PUT 具有 idempotent 语义，通用组件可以利用这些语义（例如，当对较早请求的响应在网络上丢失时自动重新发送请求）。

---

GET /features/1 by user1 
PUT /features/1 //done by user 2 
PUT /features/1 //done by user1 

user2 的 PUT 对 user1 不可见，user1 将更新旧对象的状态（id=1）在这种情况下可以做什么？

Conditional Requests。

您这样安排：(a) 来自服务器的 GET 请求包含标识表示的 validators (b) 服务器在请求缺少条件标头时响应 428 Precondition Required (c) 客户端知道从资源元数据中读取验证器，并在提交 PUT 请求时使用正确的条件标头 (d) 服务器知道在接受新表示之前将验证器与当前表示进行比较。