3

对于一直困扰我的事情，这更像是一个概念完整性问题。

HTTP 的 DELETE 方法应该是幂等的，而 REST 的 URI 应该实际代表事物。但它似乎只定义了相反的方向：每个资源必须有一个 URI，但给定的 URI 似乎不需要资源。更仁慈的是，我猜想 URI 可以定义为指向空/空资源。

这似乎真正相关的唯一一次是在 DELETE 请求中。放在哪里最好？example.com/users/内容标识要删除的资源，还是example.com/users/USERNAME更好？

DELETE 中的内容在 HTTP 和 REST 中似乎很好。（概念上：根据其他 SO 问题，各种框架会在您处理之前默默地从 DELETE 请求中删除内容。）

所以这是我的想法：每个示例似乎都使用后一种方案——您在其URI 处删除资源，而不是从其父集合URI 中删除资源——但在成功 DELETE 后该资源应该停止存在。在这种情况下，URI 应该大声失败，恕我直言。但这会否定 DELETE 的幂等性，导致我认为 DELETE 应该对集合进行操作，内容指定要删除的实际资源。

显然，每个人都只是做我不喜欢的事情，为了我的用户的理智，我可能应该同意它，但是是否有任何地方清楚地说明了这一点，或者我遗漏的明显事情让我错了?

4

2 回答 2

4

根据 HTTP 标准“DELETE 方法请求源服务器删除由 Request-URI 标识的资源”。- 没有任何类型的请求正文。

在这种情况下，URI 应该大声失败，恕我直言。但这会否定 DELETE 的幂等性

只需返回 404。幂等性的要点是，两次提交相同的 DELETE 请求不会导致服务器状态与提交一次有任何不同。失败不会导致问题（除非服务器关闭或其他）

于 2011-10-12T19:57:33.627 回答
1

DELETE请求应仅适用于您要删除的资源的 URI 。对于通过集合删除某些内容，aPOST或PUT对该集合更合适。

您可以DELETE通过检查资源并在其存在时将其删除并返回 2xx 来实现对请求的响应，否则仅返回 2xx（例如，如果发送了重复请求）。使方法具有幂等性的关键在于它不会“大声失败”——它根本不被认为是失败。就像如何PUT不区分“创建”和“更新”一样。

于 2011-10-12T20:00:29.367 回答