Chapter 4. RESTful web applications

The REST (Representational State Transfer) architectural style for web applications was first put forward by Roy Thomas Fielding ( ) in 2000, but in its essence it's a rediscovery of the merits of the good old HTT protocol. JSF applications, though, normally don't conform to the HTTP specification at all.

The basic principles of the HTTP are:

  1. HTTP is stateless.

  2. Each resource (page, article, shopping item, business object etc.) that is accessible via HTTP is being uniquely identified by its URI .

  3. Resources are being accessed via specific verbs, each of which designates the type of the requested interaction with the resource:

    1. GET for displaying a resource

    2. POST for creating a resource

    3. PUT for modifying a resource [*]

    4. DELETE for deleting a resource [*]

  4. The resources can be requested in specific content types, as needed on the client.

RESTful web applications conform to these principles, thus guaranteeing uniform access to resources regardless of their location, enabling easy integration and loose coupling between applications. Building on that, RESTful web applications make it easy to provide device-specific responses and search engine optimized URL s.

JSF applications, in contrast, are using mostly POST requests, often submitted via JavaScript and containing lots of component state information, even if the requested resource is only to be displayed. Furthermore, after completing the request, often not the current URL is being displayed in the browser's address bar but the last one (due to resctrictions in the use of Redirects). These facts account for an un-weblike feel of JSF applications - browser buttons do not work as expected, state information can become incoherent between requests, leading to application errors, and web pages are being bloated with information unrelated to the actual resources.

With JSF-Spring 4.0, we have worked hard to address these concerns and make JSF applications more RESTful. With JSF-Spring's new form and link components, you now can:

  1. Replace POST with GET requests where appropriate.

  2. Reduce state saving information and even eliminate it, making for leaner pages and applications.

  3. Re-enable the expected navigation behaviour of your application.

  4. Provide search engine friendly URL s for pages and actions.

4.1. Small state footprint


4.1.1. Stateful vs. Stateless


4.1.2. The ViewBuilder

TODO FaceletViewBuilder vs. FaceletViewHandler


4.1.3. GET and POST at a glance

TODO The OptimizedStateManager

TODO The NoStateManager


4.2. Submitting forms via GET


4.2.1. Readable URLs for GET requests


4.3. Full integration of action based web frameworks


4.3.1. Full integration of SpringMVC and JSF

TODO The FacesContextFilter

TODO The FacesDispatcherServlet

TODO Lifecycles

TODO Special PhaseListeners for Handlers

TODO Controllers

TODO The FacesController

TODO The SimpleActionController

TODO The MultiActionEventController


4.3.2. Integration with other web frameworks


[*] Since most clients don't implement these verbs, they are being simulated by POST requests.