RESTful Rails Put / Post сбой проблема

Question

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

• GET / resources / new -> POST / resources -> REDIRECT GET / resources /: new_id
• GET / resources /: id / edit -> PUT / resources /: id -> REDIRECT GET / resources /: id /

То, что для меня превратилось в серьезную проблему, - это когда проверка останавливает сохранение и возвращает обратно для рендеринга: new / render: edit Но в этот момент URI клиента указывает не на ... / new или ... /: id / редактировать больше. Это, кажется, плохо нарушает парадигму REST; потому что мы еще не изменили состояние, мы перешли. Может быть, поэтому я так долго боролся за принятие RESTful-практик в сценарии, отличном от AJAX или WebService, где вызовы могут быть сделаны и обработаны без изменения страницы. В истинном представлении ресурсов REST мы не должны указывать на ресурс /: id / edit, а просто выводить из глагола PUT.

В старые времена Rails у нас была форма / / new, возвращаемая в new с условным контроллером вроде request.post? , Если валидация по какой-либо причине не удалась, было бы нормально не перенаправлять на GET, но пользователь все еще находился в ... / new, что имело смысл. Они могли бы нажимать перезагрузку снова и снова, и пока наш Контроллер проверял новое действие для POST против GET, он просто продолжал бы выдавать ошибку или перезагружать пустую форму. В случае успеха мы будем двигаться дальше с шаблоном Get / Post / Get.

ТАК, каково общее согласие (я знаю, что мог бы взломать данные POST / PUT во флэш-памяти, но я бы предпочел что-то чистое), что делать с переключателем расположения ресурса, и при сбое, теперь отображая «новый 'form для того, что должно быть' show 'или' index ', основываясь на URI (и включая парадигму Rails' ... / new || ... / edit)?

(Вторичный вопрос: как мы должны / могли бы справиться с получением информации о ресурсе перед POST или PUT, если практикуем истинное REST, что само по себе великолепно, потому что нет никакого широковещательного контракта схемы, как, например, SOAP. Другими словами, чтобы избежать «хаков», таких как ... / edit и ... / new (это, безусловно, выглядит как плохая форма, если при подходе REST перечислить другие глаголы в URI ... / show, .. ./delete и т. д., потому что присутствие глагола в URI уменьшает его аспект как Resource, а не пары object.method)

Answer 1

Если вы действительно хотите, чтобы URL оставался прежним, вы всегда можете реализовать проверку на стороне клиента и отключить кнопку «Создать» или «Обновить»;это означает, что вы можете пропустить цикл if-else и просто выдать ошибку, если сохранение все равно не удалось.

Если вы посмотрите на XML-маршруты Rails по умолчанию, у него часто даже нет нового метода и метода редактирования, нопросто возвращает XML с сгенерированными ошибками.Это фактически то же самое для HTML, за исключением того, что Rails обрабатывает его изящно и позволяет пользователю повторить попытку немедленно.

Конечно, если вы действительно хотите избавиться от / new и / edit 'hacks' (как вы их называете), вы можете включить «новую» форму в представление индекса и включить возможность редактировать ресурс в представлении представления того же ресурса.

Еще одним улучшением будет возвращение 422 (: unprocessable_entity) вместо 200 в другом в методе создания и обновления;это часто применяется для вывода в формате XML, но в основном не для вывода в формате HTML.Тогда вы, по крайней мере, указали бы клиенту, что введенные данные неверны.