REST API应该保护背后的数据吗？

Question

在DELETE查询中，如果我的REST API盲目地继续或警告它并要求确认，可能会级联移除大量数据？

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

一个简单的例子（与真实案例无关）将是一组三个“树/分支/叶”表：叶子行对分支的ID有一个外键，并且分支行同样包括树ID。 API可以在任何级别启用DELETE，但是如果删除树项目，它将内部级联以删除直接或间接引用它的所有分支和叶子。

等了一树删除查询，该API可以：

• 只是遵守并执行所有级联清除
• 拒绝，理由是它会破坏完整性，所以你必须删除所有相关项目先手动（不太实际）
• 不要删除任何东西并发回语句“这样会删除1棵树，31个分支和987棵树叶，请确认”。确认可以采取URL（/ force）中额外的头部或后缀的形式，但这两者都不是非常REST，并且根据我的经验，在编写客户端时（通常只发送delete + confirm查询），这些东西通常会被直接绕过。我也犹豫在HTTP代码上这样回复。

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

Answer 1

像往常一样，这些问题的答案真的是'它取决于'。就个人而言，如果你会去不必“确认”大缺失的路线，我反而：

1. 添加depth或cascading头。而不是'你真的想要这个吗？'你知道要求开发人员确保他们想要进行深度删除。 Depth是标准标题，但出现在WebDAV规范中。 Cascading不会，所以你可以用X-作为它的前缀，这取决于你是否认为这是个好主意=）
2. 如果没有指定该头部，则回应409。 WebDAV就是这样做的，并且在这里有很多意义。

但是，从我的观点来看，我认为我宁愿有一个'取消删除'的选项。