批量创建、批量更新、批量删除

批量获取说完了，接下来我们来聊聊批量更新，实际上批量更新、批量创建虽然有场景，但也不多，在这种场景下，我们已经很难像批量获取那样，在原有资源上进行操作，而是需要借助批量资源来实现批量操作。

以用户资源（User）为例，当我们需要对其进行批量创建、删除、更新时，我们需要创建一个批量资源 BulkUser，并通过对 BulkUser 操作，来创建用户。Bulk User 本质上是将请求的多个资源转换为了异步的任务，在发起后，开发者可以在任务结果中查询具体的值来使用。

如何理解异步的任务？
这里异步的任务更多是一种设计表现，并不强制要求一定异步。异步的表现设计和相关的接口实现，是为了给后续留出纵向扩展的空间。既 无论是否行为是否真实异步，都需要在返回结果中返回任务 ID & 任务状态，以便于开发者自行实现异步处理的逻辑。

{
    "code":0,
    "data":{
       "job":{          "id":"123",          "status":"ok"        },
        "results":[
            {
            ...
            }
        ]
    }
}

批量创建

批量创建用户的操作和创建单个用户的操作是比较接近的，主要差异点在于 Path 上有区别，且传递参数时，会传递多个资源的属性。

批量创建用户

# request
POST /bulk_users/

{
    "users":[
        {
            // user1
            ...
        },
        {
            // user2
            ...
        }
    ]
}
# response
HTTP/1.1 200 OK
{
    "code":0,
    "data":[
       {
            // user1
            ...
        },
        {
            // user2
            ...
        }
    ]
}

批量更新用户

批量更新时，你已经知道了你需要更新的资源的 ID，因此，可以这样设计的你的接口：

#request
PUT /bulk_users?id[]=1&id[]=2

{
    "gender":"other"
}

# response
HTTP/1.1 204 No Content
{
 "code":0,
    "data":[
       {
            // id=1
            ...
        },
        {
            // id=2
            ...
        }
    ]
}

批量删除

有了上面的几个例子，批量删除就比较好定义了。就像这样：

#request
DELETE /bulk_users?id[]=1&id[]=2

# response
HTTP/1.1 200 OK
{
 "code":0,
    "data":[
       {
            // id=1
           "status":"deleted"
        },
        {
            // id=2
            "status":"deleted"
        }
    ]
}

总结

批量操作在获取场景，可以考虑通过 List + Filter 的方式，或搜索的方式来实现一套更加标准的搜索接口，而规避提供定制化的自定义接口。从规范的视角，两者都是符合规范的，也可以都对用户提供，并不互斥。而对于没办法复用的创建、更新、删除，则可以考虑使用创建异步任务的方式，来实现批量操作，给开发者一个明确的异步预期，让开发者可以自行查询业务的实现方式。