1

在我的 Rails 应用程序中销毁资源后，用户可以通过单击链接恢复它。

目前这个恢复动作被路由到相应资源控制器的destroy方法。

当此方法在数据库中找到资源时，它会销毁它并将记录移动到垃圾表中。

当它在数据库中找不到资源时，它会在垃圾表中搜索它，如果找到资源，它会恢复它。

这种做法我不是很满意，destroy方法有两个目的：销毁和恢复。

我可以在我的控制器中创建一个专用的恢复操作，但是以 REST 方式，您会将恢复请求处理放在哪里？在专用控制器中？如果是这样，使用哪种方法，PUT 或 POST？

4

4 回答 4

2

我认为 REST 纯粹主义者会创建一个名为 Trash 的新资源，由 TrashController 处理。要处理恢复，您需要在 TrashController 上执行一个名为 Restore 的操作。

URL 如下所示：

http://example.com/trash/restore/{resourceId}
于 2009-06-04T23:59:09.723 回答
1

POST 是非幂等的，这意味着如果您多次发送相同的 POST 请求，您将获得许多新项目。PUT 应该是幂等的，因为在同一资源上发生的相同更新在多次执行时应该没有副作用。

至于这个动作应该去哪里，这真的取决于你的审美感受力，以及你对 REST 的要求与保持你的 Rails 控制器干净和井井有条的程度。

毫无疑问，DeletedBob 是与 Bob 不同的资源。您可以说发送到 DeletedBobsController 的 PUT 将更新 DeletedBob 资源，可能使用“deleted=false”之类的参数来指示更新的目的。

您也可以将删除视为一种资源。然后你可以在 DeletionsController 上使用 DELETE，参数为“resource_type=bob&resource_id=23”。通过销毁删除，您正在恢复原始对象。随后的相同调用将产生“找不到对象”错误，正如人们对 DELETE 所期望的那样。

就个人而言，自从 Roy Fielding（定义 REST 的论文的原作者）出来并说POST 确实没有问题:put => :restore，我会考虑在我的 BobsController 上定义一个额外的方法和路由。它将代码保存在其他程序员期望的位置，并且他们可能是这种设计的唯一受众。

于 2009-06-05T05:37:39.547 回答
0

我认为由于该操作是针对资源的，因此该功能应该存在于 ResourceController 中。我对 RESTFUL 架构的一个工作理解是，在 PUT 和 POST 之间做出决定的经验法则是 POST 用于创建，PUT 用于更新。在这种情况下，我希望资源“存在”并且您正在更新它的状态，即您将使用 PUT 并且恢复 URI 将类似于：

http://example.com/resources/restore/ {id}

于 2009-06-04T23:34:47.743 回答
0

我认为上面的肖恩是在正确的轨道上，但我会更进一步。使垃圾操作 aPOST更新资源trash=1。然后还原只是同一资源的POST另一个trash=0

编辑：PUT用POST给定的请求替换不正确的方法不是发送整个资源，只是更新资源的一部分。

于 2009-06-05T04:03:24.950 回答