HTTP POST响应创建多个资源时的位置标头

Question

的HTTP/1.1标准规定,如果一个POST在创建一个资源的操作结果,那么该响应应该包括一个Location与新的资源的地址头部.

如果在源服务器上创建了资源,则响应应该是201(已创建)并包含描述请求状态的实体,并引用新资源和Location头(请参阅第14.30节).

在第14.30节,

对于201(已创建)响应,Location是请求创建的新资源的位置.

现在假设我的API允许POST通过将数组批量创建资源到集合资源URL.例如:

POST /books
[
    {
        "name": "The Colour of Magic",
        "published": "1983"
    },
    {
        "name": "The Light Fantastic",
        "published": "1986"
    }
]

由于\book\{bookId}已经创建了两个资源,Location在这种情况下标题的值应该是多少？

Http在多个新资源创建后发布的问题？是类似的,但它询问响应实体,而不是标题(并且没有答复).

Answer 1

我知道这个答案迟到了，但我相信最好的解决方案是创建一个带有 uuid 标识符的新“批次”资源，该资源将返回使用以下 URL 添加的图书 URL 列表：

http://api.example.com/batches/{uuid}

例如

http://api.example.com/batches/2b9b251f71a4b2901d66e04725bc0c9cb5843c74

然后您的POST或PUT可以在其Location: {url}标题和201 - Created状态代码上返回上述 URL 。

如果您然后GET该资源应以一个表示形式响应，该表示列出在该批次中创建的 URL，以及有关该批次的任何其他信息，例如其 uuid 和创建时间/日期。

{
  "uuid": "2b9b251f71a4b2901d66e04725bc0c9cb5843c74",
  "datetime": "2005-08-15T15:52:01+00:00",
  "books": [
    "http://api.example.com/books/the-colour-of-magic",
    "http://api.example.com/books/the-light-fantastic"
  ]
}

无论您选择什么，这些资源都可以有一个小时或一个月的 TTL。或者，如果你愿意，他们可以永远活着；无论您的用例需要什么。

Answer 2

RFC 2616已过时.除了历史目的,不要再看它了.

目前的规范RFC 7231说:

"如果由于成功处理POST请求而在源服务器上创建了一个或多个资源,则源服务器应该发送包含Location头字段的201(Created)响应,该字段提供所创建的主资源的标识符(Section 7.1.2)和描述请求状态的表示,同时引用新资源." - http://greenbytes.de/tech/webdav/rfc7231.html#POST

是的,当没有"主要"资源时,这没有多大帮助.