REST，HTTP DELETE和参数
是否有任何关于向HTTP DELETE请求提供参数的非RESTful？
我的情景是，我正在模拟“你确定要删除它吗？” 场景。 在某些情况下，资源的状态表明所请求的删除可能无效。 您大概可以想象一些需要确认是否需要删除的场景
我们采用的解决方案是将参数传递给删除请求，以指示继续进行删除（“？force_delete = true”）
例如
DELETE http://server/resource/id?force_delete=true
我相信它仍然是宁静的，因为：
（a）DELETE的语义没有被改变 - 用户仍然可以发送正常的DELETE请求，但是这可能会失败，并且响应的主体将解释原因。 我说可能会失败，因为（在某些情况下不值得解释的原因）没有理由提示用户。
（b）Roy的论文中没有任何内容表明它违背了REST的精神 - 为什么会存在，因为HTTP只是REST的一个实现，所以为什么传递HTTP参数很重要
有人能指出我一个明确的声明，指出为什么这不是RESTful？
在相关问题上，如果用户没有指定force_delete，那么我将返回409 Conflict - 是最合适的响应代码吗？
跟进
经过一些进一步的研究，我认为向DELETE中添加参数可能违反了几个原则。
首先是实现可能违反了“统一接口”（见Roy的论文第5.1.5节）
通过添加'force_delete'，我们在已经很好定义的DELETE方法上添加了一个额外的约束。 这个限制只对我们有意义。
你也可以争辩说它违反了“5.1.2客户端 - 服务器”，因为确认对话实际上是一个UI问题，并且不是所有的客户都想确认删除。
建议任何人？
不，它不是RESTful。 将动词（ force_delete ）放入URI的唯一原因是，如果您需要在PUT / DELETE方法不可用的环境中重载GET / POST方法。 从你使用DELETE方法来判断，情况并非如此。
在出现阻止RESTful服务执行操作的冲突的情况下，应该使用HTTP错误代码409/Conflict ，但用户仍有可能自己解决冲突。 预删除确认（如果没有真正的冲突会阻止删除）本身并不是冲突，因为没有任何东西阻止API执行请求的操作。
正如亚历克斯所说（我不知道谁低估了他，他是正确的），这应该在用户界面中处理，因为一个RESTful服务本身就处理请求，因此应该是无状态的（即它不能依靠持有人的确认关于请求的任何服务器端信息）。
如何在UI中执行此操作的两个示例是：
（*）请注意，5以前的HTML版本本身不支持PUT和DELETE HTTP方法，但大多数现代浏览器都可以通过AJAX调用来执行这两种方法。 有关跨浏览器支持的详细信息，请参阅此主题。
更新 （根据额外的调查和讨论）：
服务需要force_delete=true标志的场景违反了Roy Fielding论文中定义的统一接口。 此外，按照HTTP RFC，DELETE方法可能会在原始服务器（客户端）上被覆盖，这意味着这不会在目标服务器（服务）上完成。
所以一旦服务收到一个DELETE请求，它应该处理它，而不需要任何额外的确认（不管服务是否实际执行操作）。
我认为这是不安宁的。 我不认为宁静的服务应该处理强迫用户确认删除的要求。 我会在用户界面中处理这个问题。
如果这是一个程序的API，指定force_delete = true是否有意义？ 如果某人正在编写脚本来删除此资源，您是否想要强制他们指定force_delete = true以实际删除资源？
这是一个古老的问题，但这里有一些评论...