有哪些被证明在REST风格的Web服务中进行批处理操作的设计模式？
我试图在性能和稳定性方面实现理想和现实之间的平衡。我们现在有一个API，其中所有操作都是从列表资源（例如：GET /user）或单个实例（PUT /user/1、DELETE /user/22等）中检索。
有一些情况下，您希望更新整个对象集的单个字段。将每个对象的整个表示形式来回发送以更新一个字段似乎非常浪费。
在RPC式API中，您可以有一个方法：
/mail.do?method=markAsRead&messageIds=1,2,3,4... etc.
这里的 REST 对应是什么？或者说现在妥协一下可以吗？将一些特定操作添加到系统中以提高性能是否会破坏设计？当前客户端是 Web 浏览器（客户端使用 JavaScript 应用程序）。
一种简单的RESTful批处理模式是利用集合资源。例如，一次性删除多个消息。
DELETE /mail?&id=0&id=1&id=2
批量更新部分资源或资源属性会更加复杂。也就是说，更新每个markedAsRead属性。基本上，您将该属性视为一个桶，而不是每个资源的一部分，将资源放入其中。已经发布了一个示例，我稍作调整。
POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]
基本上，您正在更新标记为已读的邮件列表。
您还可以使用此功能将多个项目分配到同一类别中。
POST /mail?category=junk
POSTDATA: ids=[0,1,2]
显然，要进行类似iTunes的批量部分更新（例如，仅更新艺术家+专辑标题但不更新曲目标题）会更加复杂。桶子的比喻开始失效。
POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]
从长远来看，更新单个部分资源或资源属性要容易得多。只需利用子资源即可。
POST /mail/0/markAsRead
POSTDATA: true
另外，您可以使用参数化资源。这在REST模式中不太常见，但在URI和HTTP规范中是允许的。 分号用于在资源内分隔水平相关的参数。
更新多个属性，多个资源：
POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk
更新多个资源，只更新一个属性：
POST /mail/0;1;2/markAsRead
POSTDATA: true
更新一个资源的多个属性：
POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk
RESTful的创意丰富无穷。
CommandQueue.prototype.addCommand = function(command)
{
if (this.isCommand(command))
{
this.queue.append(command,true);
}
}
CommandQueue.prototype.fireRequest = function()
{
if (this.queued.length == 0)
{
return;
}
var data="data=";
for (var i = 0; i < this.queued.length; i++)
{
var cmd = this.queued[i];
if (this.isCommand(cmd))
{
data += cmd.toRequestString();
this.sent[cmd.id] = cmd;
// ... and then send the contents of data in a POST request
}
}
}
那应该能让你开始了。祝你好运！
虽然我认为@Alex的方向是正确的，但从概念上讲，我认为它应该与所建议的相反。
URL实际上是“我们正在针对的资源”，因此：
[GET] mail/1
表示获取 ID 为 1 的邮件记录。
[PATCH] mail/1 data: mail[markAsRead]=true
意思是将 id 为 1 的邮件记录进行补丁。查询字符串是一个“过滤器”，用于过滤从 URL 返回的数据。
[GET] mail?markAsRead=true
所以我们在这里请求所有已标记为已读的邮件。因此，对于这个路径的[PATCH]操作将意味着“修补已标记为true的记录”...而这不是我们想要实现的目标。
因此，遵循这种思路的批处理方法应该是：
[PATCH] mail/?id=1,2,3 <the records we are targeting> data: mail[markAsRead]=true
当然，我并不是说这是真正的REST（因为它不允许批量记录操作），而是遵循已经存在并被REST使用的逻辑。
[PATCH] mail?markAsRead=true data: [{"id": 1}, {"id": 2}, {"id": 3}]（甚至只是 data: {"ids": [1,2,3]}）不是更符合 [GET] 格式的一致性吗？这种替代方法的另一个好处是，如果您正在更新集合中的数百/数千个资源，则不会遇到“414请求URI过长”错误。 - rinogo从我的理解来看，您所说的语言“似乎”过于浪费，这表明您试图进行过早的优化。除非可以证明发送整个对象表示会严重影响性能（我们正在谈论对用户不可接受的超过150毫秒），否则没有必要尝试创建新的非标准API行为。请记住，API越简单易用，使用起来就越容易。
对于删除操作，请将以下内容发送到服务器，因为服务器不需要知道删除发生前对象的状态。
DELETE /emails
POSTDATA: [{id:1},{id:2}]
下一个思路是，如果一个应用程序在批量更新对象方面遇到性能问题，则应考虑将每个对象拆分成多个对象。这样，JSON有效载荷的大小将减少一部分。
例如，当发送响应以更新两个单独电子邮件的“已读”和“已归档”状态时，您需要发送以下内容：
PUT /emails
POSTDATA: [
{
id:1,
to:"someone@bratwurst.com",
from:"someguy@frommyville.com",
subject:"Try this recipe!",
text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1t Mustard Powder",
read:true,
archived:true,
importance:2,
labels:["Someone","Mustard"]
},
{
id:2,
to:"someone@bratwurst.com",
from:"someguy@frommyville.com",
subject:"Try this recipe (With Fix)",
text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1T Mustard Powder, 1t Garlic Powder",
read:true,
archived:false,
importance:1,
labels:["Someone","Mustard"]
}
]
我会将电子邮件的可变组件（已读、存档、重要性、标签）拆分为单独的对象，因为其他组件（收件人、发件人、主题、正文）永远不会被更新。
PUT /email-statuses
POSTDATA: [
{id:15,read:true,archived:true,importance:2,labels:["Someone","Mustard"]},
{id:27,read:true,archived:false,importance:1,labels:["Someone","Mustard"]}
]
采用另一种方法是利用PATCH。明确表示您要更新哪些属性，而其他所有属性都应该被忽略。
PATCH /emails
POSTDATA: [
{
id:1,
read:true,
archived:true
},
{
id:2,
read:true,
archived:false
}
]
人们认为应该通过提供一个包含更改数组的方式来实现 PATCH，其中包括：操作（CRUD）、路径（URL）和值更改。这可能被认为是一个标准实现，但如果你看整个 REST API，它是一个非直观的一次性操作。另外，上述实现是GitHub 实现 PATCH 的方式。
总之，可以遵循 RESTful 原则进行批处理操作，并且仍然具有可接受的性能。
谷歌云端硬盘API有一个非常有趣的系统来解决这个问题 （请参见此处）。
他们基本上将不同的请求分组到一个 Content-Type: multipart/mixed 请求中，每个单独的完整请求由某个定义的分隔符分开。批处理请求的标头和查询参数被继承到单个请求中（例如，Authorization: Bearer some_token ），除非在个别请求中被覆盖。
示例：（摘自他们的文档）
请求：
POST https://www.googleapis.com/batch
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963
--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8
{
"emailAddress":"example@appsrocks.com",
"role":"writer",
"type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8
{
"domain":"appsrocks.com",
"role":"reader",
"type":"domain"
}
--END_OF_PART--
响应：
HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT
--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35
{
"id": "12218244892818058021i"
}
--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35
{
"id": "04109509152946699072k"
}
--batch_6VIxXCQbJoQ_AATxy_GgFUk--
在我看来，Facebook的实现是最好的。
只需进行一次HTTP请求，其中包括一个批处理参数和一个令牌。
在批处理中，发送了一个包含“请求”集合的JSON。 每个请求都有一个方法属性（get / post / put / delete /等...）和一个relative_url属性（端点的URI），另外post和put方法允许"body"属性，将要更新的字段发送过去。
更多信息请查看：Facebook批处理API
在像您示例中的操作中，我会倾向于编写一个范围解析器。
制作一个可以读取“messageIds = 1-3、7-9、11、12-15”的解析器并不麻烦。这肯定会提高覆盖所有消息的总体操作的效率，并且更具可扩展性。
DELETE /my/uri/to/delete?id=1,2,3,4,5
我将其传递给我的SQL中的WHERE IN子句，效果很好，但想知道其他人对这种方法的看法。
DELETE /books/delete?id=1,2,3 当书籍 #3 不存在时的期望行为而定--使用 WHERE IN 将会无声地忽略记录，但通常我希望在 DELETE /books/delete?id=3 中如果3不存在，则返回404。 - chbrownDELETE操作旨在是幂等的，因此您不应该返回404，而应该返回204或200。 - David Keaveny