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

Question

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

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

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

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

Меня не очень устраивает этот способ, поскольку метод уничтожения имеет две цели: уничтожить и восстановить.

Я мог бы создать выделенное действие восстановления в моем контроллере, но REST-способом, где бы вы разместили обработку запроса на восстановление? В выделенном контроллере? Если да, то каким методом, PUT или POST?

Answer 1

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

URL будет выглядеть так:

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

Answer 2

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

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

Конечно, можно утверждать, что DeletedBob отличается от ресурса Bob. Вы могли бы сказать, что PUT, отправленный на DeletedBobsController, обновит ресурс DeletedBob, возможно, с помощью параметра, например «удалено = ложь», чтобы указать цель обновления.

Вы также можете рассматривать удаление как ресурс. Затем вы можете использовать DELETE на контроллере DeletionsController с параметрами «resource_type = bob & resource_id = 23». Уничтожив удаление, вы восстанавливаете исходный объект. Последующие идентичные вызовы приведут к ошибке «объект не найден», как и следовало ожидать с DELETE.

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

Answer 3

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

РЕДАКТИРОВАТЬ: заменил неправильный метод PUT на POST, если запрос не отправляет весь ресурс, просто обновление части ресурса.

Answer 4

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

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