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

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.