REST,HTTP DELETE和参数

Question

REST,HTTP DELETE和参数

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

我的情况是我正在建模"您确定要删除它吗？" 场景.在某些情况下,资源的状态表明请求的删除可能无效.你可以想象一些自己需要确认删除的场景

我们采用的解决方案是将参数传递给删除请求以指示可以继续删除("？force_delete = true")

例如

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

Run Code Online (Sandbox Code Playgroud)

我相信它仍然是宁静的:

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

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

有人能指出一个明确的陈述,指出为什么这不是RESTful？

在一个相关的问题上,如果用户没有指定force_delete然后我正在返回409 Conflict- 这是最合适的响应代码吗？

跟进

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

首先,实施可能违反了"统一界面"(参见Roy的论文第5.1.5节)

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

您还可能认为它违反了"5.1.2客户端 - 服务器",因为确认对话确实是UI问题,并且并非所有客户端都希望确认删除.

有人建议吗？

Answer 1

Mic*_*icE 76

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

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

正如亚历克斯说(我不知道是谁downvoted他,他是正确的),这应该在UI来处理,因为RESTful服务本身只是处理请求,应该是无状态的,因此(即:不能握住依靠确认有关请求的任何服务器端信息).

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

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

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

更新 (基于其他调查和讨论):

服务需要force_delete=true标志存在的场景违反了Roy Fielding的论文中定义的统一接口.此外,根据HTTP RFC,可以在源服务器(客户端)上覆盖DELETE方法,这意味着在目标服务器(服务)上不会这样做.

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

你能解释哪个REST约束被违反了吗？考虑到URI应该对客户端不透明,为什么你认为使用删除一个资源但无法删除另一个资源的HTTP DELETE不能满足客户的期望.我不确定409是返回的最佳状态代码,但除了有点奇怪的实现之外,我找不到任何被破坏的REST约束. (2认同)
@Darrel :( imho)它违反统一接口,DELETE方法没有按照HTTP标准执行.考虑一个假定标准REST服务的REST客户端 - 服务如何让客户知道它需要添加`force_delete = true`？根据HTTP RFC,可以在源服务器(客户端)上覆盖DELETE方法,这意味着在目标服务器(服务)上不会这样做.所以我的理解是,一旦服务收到DELETE请求,它应该处理它而不需要任何确认(无论服务是否实际执行操作). (2认同)
@MicE在很大程度上,我同意你的看法,这不是处理这种情况的理想方式.我只是对"它不是RESTful"标签有点挑剔.有一段时间,这句话被抛到了一切.但是,可以为媒体类型定义规则,如果您尝试删除资源并且出现错误(我会说403 forbidden将优于409),那么客户端应该尝试在相关资源上删除通过添加"force_delete = true".在某种程度上,它有点像授权.执行GET,获取401,再次添加auth标头和GET. (2认同)
@Darrel：这是一个很好的观点，谢谢。我看到人们自己贴上 *not RESTful* 标签。可能是现在服务和 Web 应用程序之间的障碍变得非常模糊，所以一组人可以从纯服务的角度来看这一点，而其他人则从混合应用程序/服务的角度来看。这就是我相信如何进行确认的真正问题所在。@Chris：更新了 - 谢谢先生一个非常有趣的话题和讨论！ (2认同)

Answer 2

Ale*_*ell 34

我认为这不是非常安宁.我不认为宁静的服务应该处理强制用户确认删除的要求.我会在UI中处理这个问题.

如果这是程序的API,那么指定force_delete = true是否有意义？如果有人在编写脚本来删除此资源,您是否要强制它们指定force_delete = true来实际删除资源？

Answer 3

Sha*_*sky 17

这是一个老问题,但这里有一些评论......

在SQL中,DELETE命令接受参数"CASCADE",该参数允许您指定还应删除依赖对象.这是一个有意义的DELETE参数示例,但"man rm"可以提供其他参数.如果没有参数,这些情况如何在REST/HTTP中实现？
@Jan,似乎是一个完善的约定,URL的路径部分标识资源,而查询字符串不(至少不一定).示例比比皆是:获取相同的资源,但采用不同的格式,获取资源的特定字段等.如果我们将查询字符串视为资源标识符的一部分,则不可能有"同一资源的不同视图"的概念没有转向非RESTful机制,如HTTP内容协商(由于许多原因,这可能是不受欢迎的).

Answer 4

Jan*_*sen 6

除了亚历克斯的回答:

请注意,http:// server/resource/id？force_delete = true标识的资源与http:// server/resource/id不同.例如,删除/ customers /？status = old或/ customers /是一个巨大的差异.

一月

是的 - 每个人都可以自由地弄乱:-) (16认同)

归档时间：	15 年，10 月前
查看次数：	113549 次
最近记录：	10 年，2 月前