何处处理REST MVC应用程序中的还原操作？

Question

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

当前此恢复操作将路由到相应资源控制器的销毁方法。

当此方法在数据库中查找的资源，它会破坏它，在一个垃圾桶表移动记录。

，如果未在数据库中找到的资源，它会搜索它在垃圾桶表，如果它发现的资源它恢复它。

我不是做的这种方式很满意，具有两个目的的破坏方法：破坏和恢复。

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

Answer 1

POST是非幂等的，如果你发送相同的POST请求很多次，你会得到很多新项目的意义。 PUT应该是幂等的，因为在同一资源上发生的相同更新在多次执行时应该没有副作用。

至于哪里这个动作应该去，这真的取决于你的审美sensibilty，你想约REST与保持你的Rails控制器干净整齐铁杆如何。

这当然是值得商榷的一个DeletedBob是从鲍勃不同的资源。你可以说发送给DeletedBobsController的PUT会更新DeletedBob资源，可能带有一个像“deleted = false”这样的参数来表示更新的目的。

您也可以将删除视为资源。然后，您可以在DeletionsController上使用DELETE参数“resource_type = bob & resource_id = 23”。通过销毁删除，您正在恢复原始对象。随后的相同调用将产生“找不到对象”的错误，就像人们对DELETE的期望一样。个人而言，自从Roy Fielding（定义REST的论文的原始作者）出来并说真的有nothing wrong with POST之后，我会考虑在BobsController上定义一个额外的:put => :restore方法和路由。它将代码保留在其他程序员期望的地方，而且他们可能是这类设计的唯一受众。

Answer 2

我认为，由于动作是在资源上，所以功能应该存在于ResourceController中。 RESTFUL体系结构的一个工作内容是，在PUT和POST之间进行判断的经验法则是，POST用于创建，PUT用于更新。在这种情况下，我希望该资源“存在”，你正在更新其状态，你会使用一个PUT和恢复URI会是这样的：

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

Answer 3

我认为REST purist会创建一个名为Trash的新资源，由TrashController处理。要处理还原，您需要对TrashController执行一项名为“还原”的操作。

的URL应该是这样的：

http://example.com/trash/restore/{resourceId} 

Answer 4

我觉得上面肖恩是在正确的轨道上，但我会采取它更进了一步。将垃圾操作设为POST，该更新资源的范围为trash=1。然后恢复只是另一种POST到相同资源与trash=0

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