MVC 1.0 in Java EE 8: Redirects and Forwards
Learn how to use redirects in MVC, and get a comparison of redirects and forwards in Java development.
Join the DZone community and get the full member experience.Join For Free
This post in my MVC 1.0 series is about Redirects and Forwards. Since the 2nd early draft, redirects became a new feature in MVC.
This post starts with the popular Post-Redirect-Get Pattern, shows how to handle redirects with JAX-RS and MVC, and compares Redirects with Forwards briefly.
The Post-Redirect-Get Pattern
The Post-Redirect-Post pattern is a popular pattern in web applications. It splits one request into two. Instead of returning a result page immediately in response to POST request, the server responds with redirect to result page. After that the browser loads the result page as if it were an separate resource. After all, there are two different tasks to be done. First is to POST input data to the server. Second is to GET output to the client.
When using MVC there are two different different ways to handle the Post-Redirect-Get Pattern. Redirects can be handled either with JAX-RS or even with MVC, which comes with an own mechanism for redirects.Source: theserverside.com
Redirects With JAX-RS
Because of the integration with JAX-RS it is possible to redirect to URLs the JAX-RS way. This means a redirect can be done by using a JAX-RS Response object as return value of the controller method which redirects. Behind the scenes it's a HTTP 303 "See Other".
This is the first way to handle redirects. Like it is visible, it is not very concise. A more compact way for handling redirects comes with MVC which is described in the following section.
Redirects With MVC
Since the 2nd early draft of MVC there is a new way to handle redirects. This way is more concise in comparison to the JAX-RS redirect.
When using the MVC redirect way, view paths have to be prefixed with "redirect:" to trigger a client redirect. This means the Post method needs a return type of String to perform a redirect.
In the previous illustration there is a post method which will be called first. This post method has a String return type and return a path to another url prefixed with "redirect:" to signalize a redirect.
In addition to that with MVC there is a new annotation. It's named @RedirectScoped and fits between the RequestScoped and the ApplicationScoped one. A RedirectScoped annotated bean spans at most two requests.
The following illustration shows the bean used in the previous post and get methods:
Like described before the bean has to be annotated with @RedirectScoped to span more than one and at least two requests. In addition to that it has to be Serializable. That's all.
Currently redirects have to be implemented with new CDI beans. The javax.mvc.Models map is RequestScoped, so it can not be used to store data over two requests. In the mailing list there is a discussion about the scope of the Models map.
Redirects vs. Forwards
With the 3rd early draft there will be a forward prefix. In comparison to redirects, forwards don't result in a response to the client. Forwards are "server internal". The forward routes to another controller url within the server with just a single request instead of two. Another difference is that the browser won't show the redirected url when using forwards. With forwards the url stays the same from the beginning post request till the end of the get request.
With MVC 1.0 there will be two different ways to support the Post-Redirect-Get pattern. Redirects can either be handled with JAX-RS Response objects or even with the new MVC 1.0 "redirect:" prefix for controller methods.
There will also be a way to forward to other urls. In comparison to redirects forwards stay on the server and only need a single request instead of two like redirects do. When using redirects the url changes from post to get an with forwards the url stays the same.
I hope you are enyoing my series about MVC 1.0 in Java EE 8. If there are any topics that you would like to see, please leave a comment. :-)
Opinions expressed by DZone contributors are their own.