REST,HTTP DELETE和参数

不,它不是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请求,它就应该处理它而不需要任何额外的确认(无论服务是否实际执行操作).

1> MicE..：

---

不,它不是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约束.

---

@Darrel :( imho)它违反统一接口,DELETE方法没有按照HTTP标准执行.考虑一个假定标准REST服务的REST客户端 - 服务如何让客户知道它需要添加`force_delete = true`？根据HTTP RFC,可以在源服务器(客户端)上覆盖DELETE方法,这意味着在目标服务器(服务)上不会这样做.所以我的理解是,一旦服务收到DELETE请求,它应该处理它而不需要任何确认(无论服务是否实际执行操作).

---

@MicE在很大程度上,我同意你的看法,这不是处理这种情况的理想方式.我只是对"它不是RESTful"标签有点挑剔.有一段时间,这句话被抛到了一切.但是,可以为媒体类型定义规则,如果您尝试删除资源并且出现错误(我会说403 forbidden将优于409),那么客户端应该尝试在相关资源上删除通过添加"force_delete = true".在某种程度上,它有点像授权.执行GET,获取401,再次添加auth标头和GET.

2> Alex Rockwel..：

---

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

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

3> Shay Rojansk..：

---

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

在SQL中,DELETE命令接受参数"CASCADE",该参数允许您指定还应删除依赖对象.这是一个有意义的DELETE参数示例,但"man rm"可以提供其他参数.如果没有参数,这些情况如何在REST/HTTP中实现？

@Jan,似乎是一个完善的约定,URL的路径部分标识资源,而查询字符串不(至少不一定).示例比比皆是:获取相同的资源,但采用不同的格式,获取资源的特定字段等.如果我们将查询字符串视为资源标识符的一部分,则不可能有"同一资源的不同视图"的概念没有转向非RESTful机制,如HTTP内容协商(由于许多原因,这可能是不受欢迎的).

4> Jan Algermis..：

---

除了亚历克斯的回答:

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

一月

---

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