Лучшие практики для Post-Redirect-Get (PRG) с MVC в PHP

Есть ли лучшая практика для шаблона PRG с MVC?
В этом уроке:
http://www.theserverside.com/news/1365146/Redirect-After-Post
предлагаемое решение требует 4 действия:
Create_Item (POST) => «сбрасывает» форму и перенаправляет на Display_Item
Display_Item (GET) => показывает форму (с временными данными и ошибками, если существует)
Store_Item (POST) => попытаться сохранить данные в БД, если ошибки, сохранить ошибки и перенаправить на Display_Item, если успех перенаправляется на Display_Stored
Display_Stored (GET) => показывает созданный элемент или сообщение об успешном завершении, tec.

Теперь я считаю, что первое действие с POST является проблемой, потому что мы не можем запустить форму со ссылкой. Использование GET в Create_Item кажется лучшим вариантом.
А также мы можем сделать то же самое с 3 действиями (используя одно и то же действие для Create_Item и Display_Item, но с дополнительным флагом для перепродажи формы, например:
http://www.example.com/controller/Create_Item/?reset=1

А также мы можем сделать то же самое всего с двумя действиями, потому что мы можем использовать if внутри Create_Item для проверки, является ли запрос GET или POST (поэтому мы объединяем Display_Item с Store_Item).

А также мы можем сделать то же самое только с одним действием, потому что у нас может быть дополнительный флаг (в запросе URL или в сеансе) для показа результатов вместо формы:
GET http://www.example.com/controller/Create_Item/?reset=1 => показывает новую форму и перенаправляет на следующий URL-адрес
GET http://www.example.com/controller/Create_Item/ => показывает форму с временными данными и ошибками, если существует
POST http://www.example.com/controller/Create_Item/ => сохранить ошибки в temp или данные в БД (и установить флаг сеанса для успеха) и перенаправить на указанный выше URL-адрес или следующий URL-адрес
GET http://www.example.com/controller/Create_Item/ => если $ _SESSION ['success'] показать результаты

Лично мне нравится идея иметь 4 действия, но у меня нет реального преимущества по сравнению с другими вариантами. Но я не чувствую себя в безопасности, выбирая свой дизайн без реальных критериев.
Кто-нибудь знает PROS и CONS каждого дизайна (если есть)?

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

    Благодаря!

    Related of "Лучшие практики для Post-Redirect-Get (PRG) с MVC в PHP"

    Шаблон состоит в том, чтобы GET пустую форму, изменить содержимое формы, а затем отправить сообщение POST на сервер, а затем отправить перенаправление на другую страницу, которая является GET , возможно, на страницу с сообщением « Form submitted successfully. , (Get ->) пост-> Redirect-> Get

    Первое действие – это не POST . Это конечный результат заполнения формы и ее отправки. В руководстве больше говорится о том, что делать после этого POST , как если бы вы не делали переадресацию, тогда пользователь остается на странице с сообщением о том, что Form submitted successfully когда они могут просто нажать F5 и сделать еще один POST . Однако при этом перенаправлении они попадают на страницу результатов с помощью безопасного GET что не приведет к двойному сообщению.

    Что касается реализации, вы должны иметь все свои действия на стороне сервера. Это встроено в реализацию MVC / RESTful.

    • GET / url? Action = new -> Вызов метода new_form () для визуализации новой формы
    • POST / url? Action = create -> вызвать метод create_form () для сохранения и перенаправления на / url? Action = show & id = 1234
    • GET / url? Action = show & id = 1234 -> метод show_form () для отображения результата
    • POST / url? Action = save & id = 1234 -> Вызов метода save_form () для сохранения и перенаправления

    Вместо этого вы могли бы использовать 3 действия, если хотите save второй вызов вызова. Большинство соглашений REST / CRUD используют 4, но выбор за вами. Выгоды такие же, как и маршрут REST / MVC.

    Смотрите также эти ресурсы:

    • Веб-службы RESTful
    • Это охватывает типичные соглашения для контроллеров RESTful. Он охватывает рельсы, но по-прежнему применяется к PHP, если вы хотите пойти по маршруту REST.