Question

我有一个api让用户添加一本书http://127.0.0.1/book
如果用户想一次创建100本书怎么办？

我找到一些讨论here
LiorH说：

Although bulk operations (e.g. batch create) are essential in many systems,  
they are not formally addressed by the RESTful architecture style.

这是一个宁静的设计建议吗？

我喜欢一次发一个项目但我的伴侣希望一次创造所有我认为如果其中一些格式有效，那么同时创建所有内容都会有问题，其中一些格式不是我想确定这个

Answer 1

我喜欢Thierry Templier的方法，正如文章Implementing Bulk Updates within RESTful Services中所述。我将总结这里的主要想法，适应你的上下文。不过，我建议阅读完整的文章：

请求

通常，POST方法用于向集合中添加单个元素。因此，我们可以拥有一个接受单个元素和其方法元素集合的资源。根据输入有效负载，处理检测是否必须完成单个或批量添加。

事实上，在/books/bulk这样的资源路径中使用另一个使用动作名称的资源实际上并不是RESTful，所以这不是正确的方法。

创建单个元素时，我们可以这样：

POST /books
Content-Type: application/json
{
    "title": "The Lord of the Rings - The Fellowship of the Ring",
    "author": "J. R. R. Tolkien",
    (...)
}

以下是批量操作的情况：

POST /books
Content-Type: application/json
[
    {
        "title": "The Lord of the Rings - The Fellowship of the Ring",
        "author": "J. R. R. Tolkien",
        (...)
    },
    {
        "title": "The Lord of the Rings - The Two Towers",
        "author": "J. R. R. Tolkien",
        (...)
    },
    (...)
]

响应

创建单个元素时，响应非常简单，通常包含两件事：

状态代码201（已创建）
标题Location包含新创建的元素的网址

201 Created
Location: http://example.com/api/book/{id}

Location标头接受一个值，并且可以在响应中定义一次。也就是说，由于POST方法的语义取决于RESTful服务设计者，我们可以利用标题Link来提供此提示，如下所述：

201 Created
Link: <http://example.com/api/book/{id}>, <http://example.com/api/book/{id}>

交易

在批量操作中，您可以考虑采用交易方法：

一切正常，所有数据都已插入
至少有一个元素有验证错误而且没有添加任何内容
一个或多个插入失败并且所有内容都已回滚

422 Unprocessable Entity
Content-type: application/json
[
    {
        "index": 1,
        "messages": [
            {
                "title": "The title should at least have three characters."
             }
        ]
    },
    {
        "index": 1,
        "messages": [
            {
                "id": "The value of the field it isn't unique."
             }
        ]
    },
]

如果是插入错误：

500 Internal Server Error
Content-type: application/json
[
    {
        "index": 1,
        "messages": [
            "The book can't be added because of the error #22 (description)"
        ]
    },
    (...)
]

对于非事务处理，响应的状态代码将始终为200，并且响应有效负载中描述了错误（如果有），如下所示：

200 OK
Content-type: application/json
[
    {
        "index": 1,
        "status": "error",
        "messages": [
            "The book can't be added because of the error #22 (description)"
        ]
    },
    {
        "index": 2,
        "status": "success",
        "auto-generated-id": "43"
    },
    (...)
]

Answer 2

REST谈论交换你关心的事物的表示。如果您关心书籍集，那么为其创建一个表示，并允许客户POST。

这些服务中棘手的部分始终是响应，因为通常的模式是在POST资源之后，您的响应是或重定向到新创建的资源的URI。

但是，没有任何东西可以让你回复一个URI列表，这意味着POST一套书的结果是一组创建的资源。

但是，这里有一个重要的警告，即失败语义。如果只创建了一些书籍，会发生什么？是否有可能只创建了一些书籍，然后客户必须处理这些？这是事情变得相当棘手的地方，这也是很多人试图避免这种情况的原因。它没有任何根本性的错误，但它使API变得非常复杂，并且性能提升可能比人们想象的要小。

有没有理由不能一次创作一本书？我建议尽可能简化API，除非你有令人信服的理由让它更复杂。

Restful Design是否支持bulkcreate？

2 个答案:

请求

响应

交易