Должен ли я использовать шаблон «post / redirect / get» в этом случае? - PullRequest
Новая
       28

Должен ли я использовать шаблон «post / redirect / get» в этом случае?

1 голос
/ 08 апреля 2011

В нашем веб-приложении я разрешаю пользователям редактировать свои профили, используя простую одностраничную форму (аналогично профилю в SO).

Я пытаюсь решить, использовать ли шаблон «post / redirect / get» в этом случае.

  • С одной стороны, после обновления пользователи могут обновить страницу профиля (или перейти к ней с помощью кнопки назад) без каких-либо назойливых сообщений браузера, спрашивающих, хотят ли они повторно отправить свои данные.

  • С другой стороны, этот шаблон требует второго запроса от браузера, а также требует, чтобы сервер дважды извлекал объект профиля (один раз для его обновления, а затем снова для его отображения наперенаправление).

  • Если мы реализуем некоторый тип репликации базы данных, существует еще одна проблема, связанная с тем, что второй запрос может перейти на другой сервер, который, возможно, не получил обновления для объекта профиля.Эта проблема может быть решена с помощью Memcache или подобной стратегии, но она добавляет дополнительную сложность.

  • «post / redirect / get» также усложняет отображение подтверждающего сообщения («Ваши изменения профиля имеютбыл сохранен "), так как теперь нам нужно было бы сохранить флаг, который предлагает отображать сообщение во втором запросе.В идеале мы хотим, чтобы наше приложение было максимально RESTful.

Как лучше всего решить эту проблему?Есть ли другие соображения, которые я пропустил?

1 Ответ

4 голосов
/ 08 апреля 2011

Всегда используйте Post-Redirect-Get.Period.

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

Трудно измерить.

Если мы реализуем какой-либо тип репликации базы данных ...

Тогда не надо.

Тебе это редко нужно.Редко.Узким местом практически во всех веб-транзакциях является загрузка из Apache на рабочий стол.Ваше приложение и база данных не узкое место.

Не используйте репликацию базы данных, пока не сможете доказать , что база данных действительно является самой медленной частью транзакции.

«post / redirect / get» также усложняет отображение подтверждающего сообщения («Ваши изменения профиля были сохранены»)

Это не «флаг».Это на самом деле очередь недоставленных сообщений.Ваш HTML-интерфейс включает в себя сеансы, а очередь сообщений является функцией объекта сеанса.HTML не является полностью RESTful, потому что - ну, люди ожидают сессий.

Чистая версия REST не имеет подтверждающего сообщения в первом GET.

...