http - REST、HTTP DELETE 和参数

Question

为 HTTP DELETE 请求提供参数有什么非 RESTful 的吗？

我的场景是我正在模拟“你确定要删除那个吗？”设想。在某些情况下，资源的状态表明请求的删除可能无效。您可能会自己想象一些需要确认删除的场景

我们采用的解决方案是，给删除请求传递一个参数，表示可以继续删除("?force_delete=true")

例如

DELETE http://server/resource/id?force_delete=true

我相信它仍然是 Restful ，因为:

(a) DELETE 的语义没有改变——用户仍然可以发送正常的 DELETE 请求，但是这可能会失败并返回 409，响应的正文将解释原因。我说可能会失败，因为(出于不值得解释的原因)在某些情况下没有理由提示用户。

(b) Roy 的论文中没有任何内容表明它违背了 REST 的精神——为什么会这样，因为 HTTP 只是 REST 的一种实现，所以为什么传递 HTTP 参数很重要

谁能给我指出一个明确的声明来说明这不是 RESTful 的原因？

在相关问题上，如果用户未指定 force_delete，那么我将返回 409 Conflict - 这是最合适的响应代码吗？

跟进

经过进一步研究，我认为在DELETE中添加参数可能会违反几个原则。

首先是实现可能违反了“统一接口(interface)”(参见 Roy's dissertation 的第 5.1.5 节

通过添加“force_delete”，我们在已经明确定义的 DELETE 方法上添加了额外的约束。这个约束只对我们有意义。

您还可以争辩说它违反了“5.1.2 客户端-服务器”，因为确认对话确实是一个 UI 问题，而且并非所有客户端都希望确认删除。

有什么建议吗？

Answer 1

不，它不是 RESTful。您应该将动词 (force_delete) 放入 URI 的唯一原因是您需要在 PUT/DELETE 方法不可用的环境中重载 GET/POST 方法。从您使用DELETE方法来看，情况并非如此。

HTTP 错误代码 409/Conflict 应该用于存在阻止 RESTful 服务执行操作的冲突的情况，但用户仍有可能解决冲突本身。删除前确认(不存在会阻止删除的真正冲突)本身并不是冲突，因为没有什么可以阻止 API 执行请求的操作。

正如 Alex 所说(我不知道是谁否决了他，他是对的)，这应该在 UI 中处理，因为 RESTful 服务本身只是处理请求，因此应该是无状态的(即它不能依赖于通过保存有关请求的任何服务器端信息进行确认)。

如何在 UI 中执行此操作的两个示例是:

• pre-HTML5:* 向用户显示一个 JS 确认对话框，并且只有在用户确认时才发送请求
• HTML5:* 使用带有删除操作的表单，其中表单将仅包含“确认”和“取消”按钮(“确认”将是提交按钮)

(*) 请注意，5 之前的 HTML 版本本身不支持 PUT 和 DELETE HTTP 方法，但是大多数现代浏览器可以通过 AJAX 调用来执行这两种方法。参见 this thread有关跨浏览器支持的详细信息。

---

更新(基于额外的调查和讨论):

服务需要 force_delete=true 标志的场景违反了 uniform interface如 Roy Fielding 的论文中所定义。此外，根据 HTTP RFC , DELETE 方法可能会在源服务器(客户端)上被覆盖，这意味着这不会在目标服务器(服务)上完成。

因此，一旦服务收到 DELETE 请求，它就应该处理它而不需要任何额外的确认(无论服务是否实际执行操作)。