REST，HTTP DELETE和参数 [英] REST, HTTP DELETE and parameters

问题描述

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

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

My scenario is that I'm modelling the "Are you sure you want to delete that?" scenario. In some cases, the state of the resource suggests that the requested delete may be invalid. You can probably imagine some scenarios yourself where confirmation of a delete is required

The solution we have adopted is to pass a parameter to the delete request to indicate that it's ok to proceed with the delete ("?force_delete=true")

例如

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

我相信它仍然是宁静的：

I believe that it's still restful since:

（a）DELETE的语义没有被改变 - 用户仍然可以发送正常的DELETE请求，但这个可能会失败与409和身体回应将解释原因。我说可能会失败，因为（出于不值得解释的原因）在某些情况下没有理由提示用户。

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

(a) The semantics of DELETE are not being changed - the user can still send a normal DELETE request but this may fail with 409 and the body of the response will explain why. I say may fail because (for reasons not worth explaining) on some occasions there is no reason to prompt the user.

(b) There's nothing in Roy's dissertation to suggest that it's against the spirit of REST - why would there be since HTTP is only one implementation of REST so why would passing HTTP parameters matter

有人能指出一个明确的声明，说明为什么这不是RESTful吗？

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

Can someone point me at a definitive statement that nails the reason why this isn't RESTful?

On a related question, if the user does not specify force_delete then I'm returning 409 Conflict - is that the most appropriate response code?

之后进一步的研究，我认为向DELETE添加参数可能违反了几个原则。

After some further research, I think that adding parameters to the DELETE may violate several principles.

首先，实现可能违反了统一接口（参见5.1.5节） Roy的论文

The first is that the implementation possibly violates the "Uniform Interface" (see section 5.1.5 of Roy's dissertation

添加'force_delete'w在正确定义的DELETE方法上添加一个额外的约束。这种约束只对我们有意义。

By adding 'force_delete' we're adding an additional constraint onto the already well defined DELETE method. This constraint is meaningful only to us.

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

You could also argue that it violate the "5.1.2 Client-Server" since the confirmation dialogue is really a UI concern and again not all clients will want to confirm deletion.

建议任何人？

推荐答案

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

No, it is not RESTful. The only reason why you should be putting a verb (force_delete) into the URI is if you would need to overload GET/POST methods in an environment where PUT/DELETE methods are not available. Judging from your use of the DELETE method, this is not the case.

HTTP错误代码 409 /冲突应该用于存在冲突阻止RESTful服务执行操作的情况，但用户仍有可能自己解决冲突。删除前确认（没有可能阻止删除的实际冲突）本身并不存在冲突，因为没有任何事情阻止API执行请求的操作。

HTTP error code 409/Conflict should be used for situations where there is a conflict which prevents the RESTful service to perform the operation, but there is still a chance that the user might be able to resolve the conflict himself. A pre-deletion confirmation (where there are no real conflicts which would prevent deletion) is not a conflict per se, as nothing prevents the API from performing the requested operation.

正如亚历克斯所说（我不知道是谁支持他，他是正确的），这应该在UI中处理，因为RESTful服务本身只是处理请求，因此应该是无状态的（即它不能依赖于确认任何有关请求的服务器端信息。）

As Alex said (I don't know who downvoted him, he is correct), this should be handled in the UI, because a RESTful service as such just processes requests and should be therefore stateless (i.e. it must not rely on confirmations by holding any server-side information about of a request).

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

Two examples how to do this in UI would be to:

• pre-HTML5 ：*向用户显示JS确认对话框，并仅在用户确认时发送请求


• HTML5 ：*使用带有操作DELETE的表单，其中表单只包含确认和取消按钮（确认将是提交按钮）

• pre-HTML5:* show a JS confirmation dialog to the user, and send the request only if the user confirms it
• HTML5:* use a form with action DELETE where the form would contain only "Confirm" and "Cancel" buttons ("Confirm" would be the submit button)

（*）请注意，5之前的HTML版本本身不支持PUT和DELETE HTTP方法，大多数现代浏览器都可以通过AJAX调用来完成这两种方法。请参阅此主题有关跨浏览器支持的详细信息。

(*) Please note that HTML versions prior to 5 do not support PUT and DELETE HTTP methods natively, however most modern browsers can do these two methods via AJAX calls. See this thread for details about cross-browser support.

更新 （基于额外的调查和讨论）：

服务需要 force_delete = true的场景要出现的标志违反了统一界面，如Roy Fielding的论文所定义。另外，根据 HTTP RFC ，DELETE方法可能会在源服务器（客户端）上被覆盖，这意味着这不是在目标服务器（服务）上完成的。

The scenario where the service would require the force_delete=true flag to be present violates the uniform interface as defined in Roy Fielding's dissertation. Also, as per HTTP RFC, the DELETE method may be overridden on the origin server (client), implying that this is not done on the target server (service).

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

So once the service receives a DELETE request, it should process it without needing any additional confirmation (regardless if the service actually performs the operation).

这篇关于REST，HTTP DELETE和参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！