Can you provide information or links that discuss using resource state over session or DB state?

Question

There is a talk here by Stefan Tilkov, where he is describing REST architecture at its core. I haven't watched all of it, but in the portion where he talks about the 5 Principles of REST (slides 12-19) he mentions maintaining state through the resource (i.e. -- the URI). His example is a shopping cart. Usually the state of your shopping cart is maintained in the session, but he makes the comment (paraphrasing here) that this is an incorrect interface implementation, since you can't "send" your session to a colleague, but you could send the resource state, which would then have all of the items in your cart. I found the concept to be interesting, and I was wondering if anyone has any additional information, resources, links, videos, etc., that actually discuss architecture implementations for this sort of thing (preferably in Java). Thanks!

EDIT:

Sorry, I'm going to make a brief edit here -- I'm not talking about wanting information on REST implementations per se, but wanting disadvantages/advantages of actually using resource state extensively over session/db state.

Answer 1

and I was wondering if anyone has any additional information, resources, links, videos, etc., that actually discuss architecture implementations for this sort of thing (preferably in Java). Thanks!

To the point, a "friendly url controller" would suffice. Create a Filter and/or Servlet which extracts the HttpServletRequest#getRequestURI() or HttpServletRequest#getPathInfo(), creates some javabean with the REST data, takes action accordingly using the command pattern and finally forwards to the JSP page in question to present the data.

Keep in mind that URL's are restricted in length to certain borders which depends on the webbrowser and webserver used. I'd recommend to not make it any longer than 255 characters. If you really need to store more information in the URL, consider GZipping and Base64encoding it and append it to the end of the URL, something like http://example.com/cart/2j34hfg5jh2g5bnvcnb2vc452. It doesn't make the URL more readable, no, but it works and can you can pass lot of information in.

Answer 2

One of the clearest explanations of the disadvantages of session state comes directly from Roy Fielding's dissertation where he introduces REST. (Emphasis is mine)

We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

Session state is therefore kept entirely on the client.

This constraint induces the properties of visibility, reliability, and scalability.

Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request.

Reliability is improved because it eases the task of recovering from partial failures [133].

Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.

Roy does go on to say the application of this constraint is a design trade-off and there are negative impacts of this choice.

Once you choose not to use session state in your application architecture, then you are left with maintaining things like shopping carts in one of two ways. Either the cart is maintained completely by the client application, or it is stored as Resource state. What makes something a Resource is that it is identified by a URI and can be manipulated by the standard verbs of the interface. If you do store the cart as a Resource, then as Stefan says you can send a link to the resource to a colleague. With this approach, the shopping cart can be implemented as you do any other resource.