RESTful删除策略

假设我有一个资源，在调用delete时可以有两种不同的行为

资源已被删除

资源将被移动到回收站

如何以符合REST的方式对其进行建模

我考虑了以下解决方案：

DELETE /myresource     

将资源移动到回收站（默认行为）

强制删除资源

---

REST合规吗？调用DELETE时，我从未在URL中看到过查询参数，可以吗？

为什么不可以？您已经在传递一个参数来标识哪个资源，因此请发送另一个参数以建立不同的操作过程。在我看来，它是完全REST的。

一个纯粹的REST策略应该更喜欢不改变的资源。在我看来，您并没有通过添加参数来更改资源，所以对我来说这听起来是个不错的策略

如果您要像这样执行相同的操作：

DELETE /myresource.force

---

这就像是另一个资源，不是最佳的。

你的想法很好，但我认为定制请求头会更合适一些。查询参数更适合于参数

自定义请求头的外观如下所示：

DELETE /myresource
X-Really-Delete: Yup

---

您还可以实现2。作为POST请求而不是DELETE

POST /myresource

recycle-bin=true...

正如您所做的一切一样，您所做的就是更新资源以指示它在回收站中

---

编辑：将方法从

PUT

更改为

POST

给定的

PUT

必须包含资源的完整替换（或添加），而这里我们显然只更新了资源的一部分。

删除应删除该项目，无需提问

遗憾的是，HTTP中没有“移动”请求。帖子通常是为了创建内容，放的是更多的修改

---

因此，我建议您使用某种形式的元数据或类似于

{“recycle”：“true”}

的json字符串执行类似于

PUT/myresource

的操作，以表明您希望“回收”它。

这打破了REST的“规则”，因为您正在处理不同的资源。同时，/myresource.json和/myresource.xml也提供了相同数据的不同格式（使用您的accept头，people！），但这不会很快消失。这不是“REST”，您是在以RPC方式执行操作。我反对您从PUT更改为POST。POST用于创建内容，PUT用于修改；OP真正做的就是用某个值标记一个资源，即更新它。@Coshman PUT是create或replace，它要求在请求中包含整个实体。可以通过补丁方法进行修改，但支持有限。。。有点PUT可以用来创建内容，POST也可以。区别在于将创建的URI放在一个特定的URI上，而POST则要求服务器确定将其存储为哪个URI。PUT还可用于完成替换资源。你说得对，真正的补丁是进行这种小更新的正确方法。在缺乏适当支持的情况下，“适当”的解决方案是获取完整的资源，对其进行更新，并将完整的更新资源放回服务器上的同一URI。

POST /myresource

recycle-bin=true...