HTTP/1.1 standard表示如果POST
操作导致创建资源,则响应应包含Location
标头以及新资源的地址。
如果已在源服务器上创建资源,则为响应 应该是201(创建)并包含一个描述该实体的实体 请求的状态,并引用新资源和位置 标题(见第14.30节)。
和第14.30节,
对于201(已创建)响应,位置是新资源的位置 这是由请求创建的。
现在假设我的API允许通过POST
数组批量创建资源到集合资源URL。例如:
POST /books
[
{
"name": "The Colour of Magic",
"published": "1983"
},
{
"name": "The Light Fantastic",
"published": "1986"
}
]
由于已创建了两个\book\{bookId}
资源,在这种情况下Location
标头的值应该是多少?
问题Http post response after multiple new resource creation?类似,但它询问响应实体,而不是标题(并且没有答案)。
答案 0 :(得分:7)
RFC 2616已过时。除历史目的外,不要再看它。
当前规范RFC 7231说:
“如果由于成功处理POST请求而在源服务器上创建了一个或多个资源,则源服务器应该发送包含Location头字段的201(Created)响应,该字段提供主资源的标识符创建(第7.1.2节)和描述请求状态的表示,同时引用新资源。“ - http://greenbytes.de/tech/webdav/rfc7231.html#POST
是的,当没有“主要”资源时,这没有多大帮助。
答案 1 :(得分:3)
我知道这个答案迟到了,但我相信最好的解决方案是使用uuid标识符创建一个新的Batches资源,该标识符将返回使用这样的URL添加的Book URL列表:
http://api.example.com/batches/{uuid}
e.g。
http://api.example.com/batches/2b9b251f71a4b2901d66e04725bc0c9cb5843c74
然后,您的POST
或PUT
可以在其Location: {url}
标题和201 - Created
状态代码上返回上述网址。
如果你然后GET
该URL,那么它将在该批次中创建的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。如果你愿意,他们可以永远活着;无论你的用例需要什么。
答案 2 :(得分:2)
我认为您处于标题Location
的特定用例中。在批量创建的情况下,处理的结果通常在返回的内容本身内提供。事实上,处理可以完全或部分成功。我的意思是所有元素都被添加或只是一个子集,结果向最终用户显示实际发生的事情。
所以我认为标题Location
在这种情况下不可用。我看到状态代码的两个选项:
但是,如果您的资源以异步方式处理批量创建,则可以注意到状态代码 202 。但是在上下文中,您需要提取资源以获取插入的状态。
关于回复的内容,您可以自由选择。我们可以想象这样的事情:
{
"took": 4,
"errors": true | false,
"items": [
{ "added": true,
"error": null
"id": "123"
},
{ "added": false,
"error": {
"code": "err12",
"description": "validation error (field type, ...)"
}
"id": null
}
]
}
ElasticSearch通过创建提供此类批量API,还提供更新和删除支持 - 有关详细信息,请参阅此链接:http://www.elastic.co/guide/en/elasticsearch/guide/current/bulk.html。
以下是类似的问题,可以提供一些提示:
希望它可以帮到你, 亨利