Post/Redirect/Get pattern for web applications

Post/Redirect/Get pattern for web applications

Posted by: Michael Jouravlev on ?? 14, 2003 DIGG

原文地址： http://www.theserverside.com/patterns/thread.tss?thread_id=20936

Being able to refresh a web page in the web application is an important usability feature. Also it is an MVC concept showcase: web page is a view for the underlying model, it is a window through which a user looks at the data.

Two most popular browsers: MSIE and Netscape/Mozilla have different names for the page refresh operation. IE uses more user-friendly "refresh", while Netscape uses more technical "reload". I prefer "reload" as a more correct term, but in fact both reload and refresh operations take place when a user tries to renew the page in the browser.

Very often a user is completely unaware that browser resends information to the server during page reload. Even if a browser warns user that information should be resent to the server, a user often cannot understand the technical meaning of the warning. Let us trace what happens during standard form submission process.

* The first page containing an input form could be obtained from the server using either GET or POST. If GET was used, then a user can refresh this page without seeing nagging "Information must be resend" message. Still, if this GET has attached parameters, they would be resent to the server.
* After a user fills out the form, it is submitted to the server. POST method is usually used for sending forms.
* Server responds with a result page.

The result page may look completely innocent, with no forms or any active elements, just some boring results from the database. For anyone remote from the internet development it seems completely legal and easy to refresh this page. Most people think that word "refresh" means exactly what it sounds: reload the page with its data from the server.

But in fact to refresh the result page would mean to re-issue the same request to the server which was used to obtain the page at the first place. That means, to do the whole POST of the form from the first page again. Here is where a user sees the "Information must be resend" message. Resending of the information may produce unwanted or inconsistent modifications of underlying data. Thus, these form resubmits must be properly handled by controller and model.

Now we are getting to the problem: because browser needs to resend the whole original request to obtain the result page, the refresh operation is not really MVC-compliant because user data is sent to the server. The solution of problem is quite simple – redirection.

This technique is actually pretty well known, but it is not standard yet for "after-post" results, and it does not have a well-known name. I call it "PRG request pattern", because it consists of three major parts: Post, Redirect and Get. The first one actually is not necessarily a POST, it is just that POST is most often used to send user data to the server. The last one must be GET so user would not see nagging messages. PRG request works in two stages:
* First a user-filled form is sent to the server using either POST or GET method. Server stores the information, updates the database and business model data, and replies with REDIRECT response for a View page.
* Browser loads View using GET, no user data is sent to the server at this point.

Now we have a clean MVC solution. When a user tries to refresh a result page, browser resends to the server "empty" GET request. All needed data is already on the server, so server just fills it in the page and sends back to the user.

What about back button? This works too, it returns us one step backwards, to the page with a form. This form can be refreshed as well. If it was obtained using GET, then user would not see warning message.

Page refresh works perfectly with redirection. We have to do the roundtrip to the browser, but one more second spent for redirection means little for interactive applications.

The only thing that have to be dealt with is intentional form resubmitting which happens when a user returns to the first page using Back button and submits form again. This should be checked by controller and a model and is out of scope of this pattern.

Bottom line: the PRG pattern provides the following benefits:
* it separates the View from Model updates;
* result page refresh does not cause form resubmit;
* page refresh is done using GET, so no messages are shown to a user