I was wondering about the best way to implement a “Confirm Page” upon form submission. I know that it’s best for the script that a form POSTs to be implemented by handling the POST data and then redirecting to another page, so the user isn’t directly viewing the page that was POSTed to.
My question is about the best way to implement a “Confirm before data save” page. Do I
-
Have my form POST to a script, which marshals the data, puts in a GET, and redirects to the confirm page, which unmarshals and displays the data in another form, where the user can then either confirm (which causes another POST to a script that actually saves the data) or deny (which causes the user to be redirected back to the original form, with their input added)?
-
Have my form POST directly to the confirm page, which is displayed to the user and then, like #1, gives the user the option to confirm or deny?
-
Have my form GET the confirm page, which then does the expected behavior?
I feel like there is a common-sense answer to this question that I am just not getting.
If you must do this (I’d only do it for stuff involving monetary transactions or the like, personally), I’d recommend 2 resources/URIs, both of which follow the Post-Redirect-Get pattern: POST the initial cart checkout, create a “pending order” state (or similar), redirect to the page for that state. The user can then POST from that page to the next URI to create a “confirmed order” (or similar), which redirects to a receipt page or whatever.