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.

首先是实现可能违反了统一接口"(参见 罗伊的论文

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

通过添加force_delete"，我们在已经明确定义的 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/Conflict 应该用于存在阻止 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)

(*) 请注意，HTML 5 之前的版本本身不支持 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屋！