restapi中批量删除的处理

我正在设计RESTAPI，即将处理批处理单删除。阅读了很多，了解不建议允许批量删除。并且不会尝试向多个ID提供参数或进行任何后期攻击

我得出的结论是：

DELETE /resources/{ID}:IamSure

删除id为{id}的资源

DELETE /resources/:IamSure[?filters][sort][limit] 

在限制内删除与可选筛选器匹配的资源

：我确信

是一种“确认方法”，因此不可能错误地调用

删除

，而不是

获取

。如果添加了

：i确保
，其他方法将抛出错误

所有上述功能：

将JSON（可能是ziped）中操作成功后发送的全部已删除资源以及响应备份到云：

/backup/resources/[{ID}/]apiuser_datetime

2更多功能：

GET/backup/resources/[{ID}]
-返回与URL匹配的备份URI列表（/resource/[{ID}]）

GET/backup/resources/[{ID}/]apiuser\u datetime
-返回备份正文

备份正文可直接用于重新创建所有已删除的资源。若某些连接的资源丢失，API将抛出错误

因为我已经为API用户/应用程序建立了范围和方法能力系统，在系统用户（拥有“API用户/应用程序”）的对象能力系统之上，这两个系统允许的任何API用户
获取
特定资源/s也将能够
获取/备份该资源/s-因为方法，范围和对象功能匹配

任何恶意或随机删除资源的尝试都会被记录（谁和何时）并且是可逆的-只需将正文发布到同一URL即可

删除操作并不常见，所以我（现在）不担心存储——特别是因为它是云计算的，很少被访问

你认为这篇文章有什么缺点/问题吗

编辑：


是否为批量删除添加其他确认，如“IamReallySure”？所以“我忘了id”不会造成大破坏

或者您会不需要确认就离开DELETE/resource/{ID}，因为这是REST中的标准行为

如果它不符合主题，我将把它移到那里。这里有一些关于REST设计的讨论，所以我认为它是正确的地方。这个问题似乎与有趣的设计密切相关。错过了。谢谢你，罗曼。