RESTful 资源 - 接受对象列表

Question

我正在构建一组 RESTful 资源，其工作方式如下:(我将使用“people”作为示例):

获取/people/{key}
- 返回一个人对象 (JSON)

GET/people?first_name=鲍勃
- 返回“first_name”为“Bob”的人员对象列表(JSON)

PUT/人/{key}
- 期望有效负载 (JSON) 中的人对象，更新人
具有在 URL 参数中找到的 {key} 以匹配有效负载的数据存储。
如果是新对象，则客户端指定新对象的键。

到目前为止，我对设计感到非常满意(尽管欢迎提出任何意见/批评)。

我还希望能够列出人员列表，但是我对我的设计的 REST 性没有信心。这就是我的想法:

PUT/人
- 期望 JSON 形式的对象列表，其中包含对象中的键
(“键”:“32948”)。更新数据存储中的所有相应对象。

这个操作是幂等的，所以我想使用“PUT”。然而，它违反了规则，因为对同一资源的 GET 请求不会返回客户端刚刚 PUT 的等价物，而是返回所有“人”对象(因为查询中没有过滤器)。我怀疑这里还有一些其他规则可能会被打破。

有人在我之前的一个问题中提到了“PATCH”请求的使用:REST resource with a List property

“PATCH”听起来很棒，但我不想使用它，因为它还没有被广泛使用，并且还与许多程序和 API 不兼容。

我不想使用 POST，因为 POST 意味着请求不是幂等的。

有没有人有任何意见/建议？

跟进:::

虽然我对使用 POST 犹豫不决，因为它似乎是 RESTful 操作的最小公分母，包罗万象，并且可以说更多关于此操作的内容(特别是它是幂等的)，但不能使用 PUT，因为它的要求太窄.具体来说:资源没有被完全重写，并且等效的资源没有从 GET 请求发送回相同的资源。当应用程序、api 和/或程序员尝试使用资源并遇到资源的意外行为时，使用具有超出其规范的属性的 PUT 可能会导致问题。

除了接受的答案之外，如果操作绝对必须是 PUT 并且将 UUID 附加到资源路径的末尾，那么 Darrel Miller 有一个很好的建议，以便等效的 GET 请求将返回等效的资源。

Answer 1

POST表示除 GET 之外的一般操作, PUT , 和 DELETE (通用哈希表操作)。由于通用哈希表操作不合适，请使用 POST . POST的语义由实体所属的资源决定 POST编。这与众所周知的通用哈希表方法的语义不同。

POST /people/add-many HTTP/1.1
Host: example.com
Content-Type: application/json

[
  { "name": "Bob" },
  { "name": "Robert" }
]