0

Below is an extract of book "JSF 2.0: The Complete Reference" (also seen on Ed Burns' blog):

Michael Jouravlev, in his influential August 2004 article Redirect After Post, described a problem that many web applications present. He described the problem as follows:

All interactive programs provide two basic functions: obtaining user input and displaying the results. Web applications implement this behavior using two HTTP methods: POST and GET respectively. This simple protocol gets broken when an application returns a web page in response to a POST request. Peculiarities of the POST method combined with idiosyncrasies of different browsers often lead to an unpleasant user experience and may produce an incorrect state of the server application.

To address the problem, Jouravlev described a technique that he called POST-REDIRECT-GET, or the PRG pattern for short. The rules of the pattern are as follows:

  • Never show pages in response to POST
  • Always load pages using GET
  • Navigate from POST to GET using REDIRECT

We have seen that JSF violates the first of these rules by using POST for every page navigation via the RequestDispatcher.forward() method from the Servlet API. Indeed, most popular Java Servlet–based Web frameworks, including Struts, use this approach for navigation. HTTP purists rightly point out that this approach violates the first rule in the PRG pattern. Not only did JSF violate the first rule, but until JSF 2.0, it was very difficult to do it any other way. Thanks to another JSF contribution from the Seam team at JBoss, it is now much easier to do PRG with JSF.

First of all, I have failed to make myself explain the problem that he was trying to address. (how the protocol gets broken when an application returns a web page in response to a POST request)

Secondly, even though I know very well what redirect, POST & GET means, I am facing problem what will, in essence, force me to navigate from POST to GET using REDIRECT and why should I as (extract of book "JSF 2.0: The Complete Reference" continued):

Whether or not to use redirects largely depends on whether what is shown in the address bar of the browser matters or could be confusing if the page referenced no longer matches the page being rendered. Another important consideration of when to use redirects is performance. Using a redirect will terminate the current request and cause a new request response cycle to occur. If the page has a very large set of components, this could have a noticeable performance impact. Redirects can also necessitate an extra round trip to reinstantiate any request-scoped objects that have disappeared by the next request.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Farhan stands with Palestine
  • 13,890
  • 13
  • 58
  • 105
  • It describes the story about the PRG design pattern. What do you want others to do with it particularly in their answer(s)? – Tiny Dec 21 '14 at 12:12
  • @Tiny: OP failed to put citations in blockquotes with references to original sources, hereby making his question completely confusing. I tidied up it. – BalusC Dec 22 '14 at 08:17
  • @Shirgill: the key answer is "idempotence" aka "bookmarkability". This is fleshed out in the answer of among others the following questions: http://stackoverflow.com/q/15521451 (also check out the "See also" section at the bottom of that answer) and http://stackoverflow.com/q/13249844. Which one do you accept as duplicate? – BalusC Dec 22 '14 at 08:21

0 Answers0