Rails Best Practices для методов RESTful контроллера CREATE и UPDATE

Question

ОК, я пытаюсь понять лучшие методы для методов CREATE и UPDATE для форматов HTML и XML.Код по умолчанию для контроллера, который генерирует генератор рельсов, для меня немного неясен.

Для метода CREATE, при хорошем сохранении, генератор говорит: " redirect_to (@whwhat) "для HTML и" рендер: xml => @whothing,: status =>: созданный,: location => @ независимо"для XML.

При плохом сохранении генератор говорит " render: action => 'new' " для HTML и " render: xml => @ what.errors,: status=>: unprocessable_entity"для XML.

Однако для метода UPDATE, с хорошим обновлением, генератор говорит:" redirect_to (@whwhat)"для HTML и" head: ok"для XML.

И, при плохом обновлении, генератор говорит" render: action => 'edit'"для HTML и" render: xml => @ what.errors,: status =>: unprocessable_entity"для XML.

Я понимаю это, и это имеет смысл для меня, и работает просто отлично - НО,У меня есть два вопроса:

Во-первых, для успешного CREATE и UPDATE в формате HTML, почему " redirect_to (@whwhat) " вместо " render: action => 'show«"?Я понимаю разницу между перенаправлением и рендерингом, просто мне интереснее, как вы, ребята, это делаете и почему.Похоже, что перенаправление было бы ненужной дополнительной поездкой для браузера.

Во-вторых, почему " head: ok " при успешном обновлении через XML, но " render: xml=> @whwhat,: status =>: созданный,: location => @ what"после успешного CREATE через XML?Это кажется противоречивым для меня.Похоже, что успешное ОБНОВЛЕНИЕ через XML должно быть таким же, как успешное СОЗДАНИЕ через XML.Похоже, вам нужно вернуть новый / обновленный объект, чтобы вы могли проверить его.Как вы, ребята, делаете это и почему?

Answer 1

Я уже написал это, когда Сэм С ответил, но здесь все равно: -)

Для первой части - зачем перенаправлять вместо рендера?Я могу придумать две причины:

1) Это соответствует.Если вы отобразили действие show и пользователь позже использует кнопку «Назад» для возврата на эту страницу, пользователь увидит неожиданное поведение.В некоторых версиях IE возникает какая-то ошибка времени ожидания сеанса IIRC, другие браузеры могут обрабатывать ее более изящно.

То же самое, если пользователь добавил эту страницу в закладки и вернулся к ней позже, используяПОЛУЧИТЕ запрос - они не увидят действие шоу.Ваше приложение может выдать ошибку или может обработать действие индекса, потому что пользователь запрашивает URL-адрес, такой как http://my.app.com/users,, который будет сопоставлен с действием индекса при использовании запроса GET.

2), если вы визуализируетедействие show без перенаправления на запрос GET и пользователь нажимает кнопку обновления, ваш браузер повторно отправит запрос POST со всеми теми же данными, потенциально создавая дублированные экземпляры того, что вы создали.Браузер предупредит пользователя об этом, чтобы он мог его прервать, но это может привести к путанице и ненужным неудобствам.

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

Answer 2

При создании или обновлении, redirect_to(@whatever), чтобы очистить сообщение, чтобы пользователь не отправлял повторно при обновлении.Он также показывает правильный URL-адрес в адресной строке для случая создания, который публикует путь сбора (/whatevers).

head :ok дает минимальный ответ при обновлении, когда обычно у вас уже есть объектв дом.Если вы обновляете страницу после обновления, стандартным методом является использование представлений rjs для обновления элементов dom и визуализации партиалов.