Где обработать действие восстановления в приложении REST MVC?

Question

После уничтожения ресурса в моем приложении Rails пользователь может восстановить его, нажав на ссылку.

В настоящее время это действие восстановления перенаправляется в метод destroy соответствующего контроллера ресурсов.

Когда этот метод находит ресурс в базе данных, он уничтожает его и перемещает запись в таблицу корзины.

Когда он не находит ресурс в базе данных, он ищет его в таблице корзины и, если находит ресурс, восстанавливает его.

Я не очень удовлетворен таким способом выполнения, поскольку метод destroy преследует две цели:разрушать и восстанавливать.

Я мог бы создать специальное действие восстановления в моем контроллере, но в REST-режиме, где бы вы разместили обработку запроса на восстановление?В выделенном контроллере?Если да, то с помощью какого метода ПОСТАВИТЬ или ОПУБЛИКОВАТЬ?

Answer 1

POST неидемпотентен, что означает, что если вы отправите один и тот же запрос POST много раз, вы получите много новых элементов.PUT должен быть идемпотентным, поскольку одно и то же обновление, происходящее на одном и том же ресурсе, не должно иметь побочных эффектов при многократном выполнении.

Что касается того, куда следует направить это действие, это действительно зависит от вашей эстетической чувствительности и того, насколько жестко вы хотите относиться к REST, а не к поддержанию чистоты и организованности ваших контроллеров Rails.

Конечно, можно утверждать, что DeletedBob - это ресурс, отличный от Bob.Вы могли бы сказать, что PUT, отправленный на DeletedBobsController, обновит ресурс DeletedBob, возможно, с параметром типа "deleted= false", чтобы указать цель обновления.

Вы также могли бы рассматривать Удаления как ресурс.Затем вы могли бы использовать DELETE в DeletionsController с параметрами "resource_type=bob&resource_id=23".Уничтожая удаление, вы восстанавливаете исходный объект.Последующие идентичные вызовы выдадут ошибку "объект не найден", как и следовало ожидать при УДАЛЕНИИ.

Лично с тех пор, как Рой Филдинг (первоначальный автор диссертации "Определение отдыха") выступил и сказал, что на самом деле ничего плохого в ПОСТЕ, я бы рассмотрел возможность определения дополнительного :put => :restore метод и маршрут на моем BobsController.Он сохраняет код там, где его ожидал бы другой программист, и они, вероятно, являются единственной аудиторией для такого рода дизайна.

Answer 2

Я думаю, что пурист REST создал бы новый ресурс под названием Trash, который обрабатывается TrashController.Чтобы обработать восстановление, у вас должно быть действие в TrashController с именем Restore.

URL-адрес будет выглядеть следующим образом:

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

Answer 3

Я думаю, что поскольку действие выполняется на ресурсе, функциональность должна находиться в ResourceController .Одно из моих рабочих пониманий архитектуры RESTFUL заключается в том, что эмпирическое правило при выборе между PUT и POST заключается в том, что POST используется для создания, а PUT - для обновлений.В этом случае я бы ожидал, что ресурс "существует", и вы обновляете его состояние, чтобы вы использовали PUT, а URI восстановления был бы чем-то вроде:

http://example.com/resources/restore/{идентификатор}

Answer 4

Я думаю, что Шон выше был на правильном пути, но я бы сделал еще один шаг вперед.Сделайте действие по удалению мусора POST это обновляет ресурс с помощью trash=1.Тогда восстановление - это просто еще один POST к тому то же самое ресурс с trash=0

Редактировать:Заменен неправильный метод PUT с POST учитывая, что запрос отправляет не весь ресурс целиком, а просто обновление части ресурса.