Как ошибки на стороне сервера обрабатываются в шаблоне Post/Redirect/Get?

В случае успешного использования рабочий поток Post/Redirect/Get (PRG) довольно прост: просто перенаправляйте (на стороне клиента) на нужную страницу. Но как насчет случаев, когда ошибки встречаются во время проверки на стороне сервера, и мы хотим сохранить входы при повторном отображении страницы ввода?

Насколько я могу судить, существуют два подхода: просто повторно отрисуйте страницу ввода после отправки формы POST (т.е. никакого перенаправления) во время ошибок (таким образом, игнорируя шаблон PRG); или, перенаправляя на страницу ввода и сохраняя предыдущие входы где-нибудь, он может быть получен позже (например, сеанс) во время рендеринга. У обоих есть свои недостатки: во-первых, нам представлены проблемы с шаблоном PRG, который помогает нам избежать (например, возможность закладки, двойное представление); второй подход приводит к несогласованным GET (первый GET найдет сохраненные входы, последующие GET не могут). Существуют ли другие альтернативы упомянутым здесь? Я надеюсь получить от сообщества информацию о том, как лучше всего обрабатывать этот случай.

Ответ 1

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

Ответ 2

Если URL-адрес, используемый для заполнения формы, является формой POST-сообщений формы, я не думаю, что есть проблема. Если вход действителен, переадресация и GET. Если он недействителен, повторно заполните заполненную форму. Таким образом, взаимодействие выглядит так:

GET  /your-url => blank form
POST /your-url (success) => Redirect => GET /success-url
POST /your-url (failure) => filled-in form

Ответ 3

Указанная проблема закладок влияет на оба подхода, вы не можете пометить что-то, что полагается на некоторые временные данные, сохраненные на сервере.

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

Таким образом, PRG только на успех - очень чистый подход.

Ответ 4

Как и другие ответы, используйте только шаблон Post/Redirect/Get при успешной проверке на стороне сервера. Если форма недействительна, просто ответьте на ответ напрямую, с сообщениями об ошибках.

Для удобства использования вы должны убедиться, что проверка на стороне клиента отличная. Это хорошая идея, так как пользователям нравится немедленная обратная связь. Используйте Javascript или новые функции формы HTML5, такие как атрибут required или атрибут maxlength или type="email" и т.д..

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

Ответ 5

Если вы используете ASP.NET MVC, тогда есть другой метод, который можно использовать для ситуации Post → failure. Это описано в статье 13 этой статьи: Лучшие рекомендации ASP.NET MVC (часть 1).

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