How do you handle all the ways you could dispatch from a HTTP POST?

Question

Imagine a user has just posted data to your web application and you want to re-display the current page with a message about their success or failure. This gets complicated.

If the data is valid and the user is expecting html, you want to issue a redirect so that refreshing doesn't cause them to re-post. You want to redirect to the referer, if it exists, and display a message. If they are not expecting html, you can simply return 200 OK.

If the data is invalid and the user is expecting html, you want to re-render the page they came from, with a visible error, so that they can re-post. To do this, you'd have to run the previous action, and make it aware of the error message. To decide which was the previous action, perhaps you included that as a hidden parameter in the form. If they are not expecting html, you can return an applicable 4xx client error.

I find myself doing this silly dance far too many times. So the questions are:

1) How would you abstract this whole process so that any form post can take advantage of it?

2) What's the most maintainable or least repetitive way to achieve this in your favorite web framework?

3) Is there anything you would change to this whole process that would make it simpler?

Idea 1: Never render on a post, always redirect. Stuff the error data in the session for a split second between requests, and then clear it, just like the success message. That way, valid and invalid posts can be handled the same way.

Idea 2: Don't do any normal HTTP posts. Only use ajax. Now you don't have to worry about rendering or redirecting at all. This would only be useful if you have an ajax-heavy application already.

Answer 1

Idea 2 is out the window. That's a horrible idea and not necessary at all. AJAX is nice, but don't overdo it. Not to mention - what about that chunk of users with Javascript disabled?

I think what you're thinking about (without really knowing it) is the Post/Redirect/Get pattern. It is the best practice when it comes to this, and you should follow it. Basically, as you said, you never respond to a POST by anything other than a redirect. As far as notifications, most of the time you know where they're coming from because of the particular action. If you don't, the HTTP REFERER is a decent alternative. Yes it can be disabled, but that's ~1% of your users, if that. As far as notifications, sessions are perfect for this. Just store the code and message in the current session and make your template aware of them. Print out the message if it exists and delete the session variables.

Answer 2

There is no shame in doing postbacks and you cannot really avoid postbacks because it's the easiest way to persist data across HTTP requests. That or query parameters which is still another round trip to the server so it amounts to the same thing with a few trade-offs. Using View state or sessions is not recommended.

Ideally the same page will check if the request is a post back and handle all the logic there in. So more often than not, your code behind or application pages with forms will have a section to handle a post back.