REST,HTTP DELETE和参数?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (48)

是否有任何关于向HTTP DELETE请求提供参数的非RESTful?

我的情景是,我正在模拟“你确定要删除它吗?” 场景。在某些情况下,资源的状态表明所请求的删除可能无效。您大概可以想象一些需要确认是否需要删除的场景

我们采用的解决方案是将参数传递给删除请求,以指示继续进行删除(“?force_delete = true”)

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

我相信它仍然是宁静的,因为:

(a)DELETE的语义没有被改变 - 用户仍然可以发送正常的DELETE请求,但是这可能会失败,并且响应的主体将解释原因。我说可能会失败,因为(在某些情况下不值得解释的原因)没有理由提示用户。

(b)为什么会有HTTP,因为HTTP只是REST的一个实现,那么为什么传递HTTP参数很重要

有人能指出我一个明确的声明,指出为什么这不是RESTful?

在相关问题上,如果用户没有指定force_delete,那么我会返回409 Conflict- 是最合适的响应代码吗?

跟进

经过一些进一步的研究,我认为向DELETE中添加参数可能违反了几个原则。

首先是实现可能违反了“统一接口”

通过添加'force_delete',我们在已经很好定义的DELETE方法上添加了一个额外的约束。这个限制只对我们有意义。

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

建议任何人?

提问于
用户回答回答于

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

409/Conflict在出现阻止RESTful服务执行操作的冲突的情况下,应该使用HTTP错误代码,但用户仍有可能自己解决冲突。预删除确认(如果没有真正的冲突会阻止删除)本身并不是冲突,因为没有任何东西阻止API执行请求的操作。

正如亚历克斯所说(我不知道谁低估了他,他是正确的),这应该在用户界面中处理,因为一个RESTful服务本身就处理请求,因此应该是无状态的(即它不能依靠持有人的确认关于请求的任何服务器端信息)。

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

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

(*)请注意,5以前的HTML版本本身不支持PUT和DELETE HTTP方法,但大多数现代浏览器都可以通过AJAX调用来执行这两种方法。

用户回答回答于

我认为这是不安宁的。我不认为宁静的服务应该处理强迫用户确认删除的要求。我会在用户界面中处理这个问题。

如果这是一个程序的API,指定force_delete = true是否有意义?如果某人正在编写脚本来删除此资源,是否想要强制他们指定force_delete = true以实际删除资源?

扫码关注云+社区