REST API应该保护数据吗？

Question

在DELETE查询中可能会级联到删除大量数据，我的REST API是否会盲目地进行或发出警告并要求确认？

我正在构建一个API，用于抽象存储在关系数据库中的复杂数据的操作。删除其他项引用的项应该从逻辑上删除它们，然后级联。

一个简单的例子（与真实情况无关）将是一组三个＆＃34; Tree / Branch / Leaf＆＃34; tables：Leaf行具有Branch的id的外键，而Branch行类似地包含Tree id。 API在任何级别启用DELETE，但是如果删除Tree项，它将在内部级联以删除直接或间接引用它的所有Branch和Leaf。

因此，对于树的DELETE查询，API可以：

• 只是遵守并执行所有级联删除
• 拒绝理由是它会破坏完整性，所以你必须先手动删除所有相关物品（不太实用）
• 不要删除任何内容并发回声明＆＃34;这将删除1棵树，31个分支和987个叶子，请确认＆＃34;。确认可以采用URL（/ force）中的附加标题或后缀的形式，但两者都不是REST，根据我的经验，这些东西通常在编写客户端时直接被绕过（实际上只发送了delete + confirm查询）。我也对这个回复的HTTP代码犹豫不决。

我倾向于认为API应该保持简单，并且傻瓜保护应该在客户端，但会欣赏外部智慧。

Answer 1

像往常这样的问题，答案真的是“它取决于”。就个人而言，如果您选择“确认”大量删除的路线，我会改为：

1. 添加depth或cascading标头。而不是'你真的想要这个吗？'你知道要求你的开发人员确保他们想要进行深度删除。 Depth是标准标题，但出现在WebDAV规范中。 Cascading不会，因此您可以在X-前面添加前缀，具体取决于您是否认为这是一个好主意=）
2. 如果未指定标头，则回复409。这就是WebDAV如何做到这一点并在这里有很多意义。

然而，从我的观点来看，我认为我宁愿选择“取消删除”。