从我的理解来看,您所说的语言“似乎”过于浪费,这表明您试图进行过早的优化。除非可以证明发送整个对象表示会严重影响性能(我们正在谈论对用户不可接受的超过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 原则进行批处理操作,并且仍然具有可接受的性能。