批量创建、批量更新、批量删除
批量获取说完了，接下来我们来聊聊批量更新，实际上批量更新、批量创建虽然有场景，但也不多，在这种场景下，我们已经很难像批量获取那样，在原有资源上进行操作，而是需要借助批量资源来实现批量操作。
以用户资源（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 的方式，或搜索的方式来实现一套更加标准的搜索接口，而规避提供定制化的自定义接口。从规范的视角，两者都是符合规范的，也可以都对用户提供，并不互斥。而对于没办法复用的创建、更新、删除，则可以考虑使用创建异步任务的方式，来实现批量操作，给开发者一个明确的异步预期，让开发者可以自行查询业务的实现方式。
