Imagine that the user has just published the data in his web application, and you want to redisplay the current page with a message about their success or failure. This is getting complicated.
If the data is valid and the user is expecting html, you want to send a redirect so that the update does not result in a resubmission. You want to redirect to the referent, if one exists, and display the message. If they do not expect html, you can simply return 200 OK.
If the data is invalid and the user expects html, you want to redisplay the page from which they came with a visible error so that they can resend the message. To do this, you will need to run the previous action and report it an error. To decide what was the previous action, you may have included this as a hidden parameter in the form. If they do not expect html, you can return the applicable 4xx client error.
I find myself doing this stupid dance too many times. So the questions are:
1) How would you abstract this whole process so that any form post can use it?
2) What is the most supported or least repetitive way to achieve this in your favorite web environment?
3) Is there anything you can change to the whole process that will simplify it?
Idea 1: Never display a message, always redirect. Configure session error data for a split second between requests, and then clear it as a success message. Thus, valid and invalid messages can be handled the same way.
Idea 2: do not make any normal HTTP messages. Use only ajax. Now you don’t have to worry about rendering or redirecting at all. This would only be useful if you already have an ajax-heavy app.
source
share