Are RESTful paths the right thing for session settings?

Question

I have a dilemma.

My web application deals with subjects like people, places, assets (e.g. images), tags, etc for which I am using RESTful routes generated by map.resources in my routes.rb.

Visitors can set various options for viewing this data, e.g sort order, selection my asset type, owner, or associated tags, and type of view. These options are sticky so that if the visitor navigates away then when they come back to the assets view the same options will be in force.

To this end I created a SessionController and associated restful routes with map.resource. The update method takes parameters such as asset_type, view_type and owner_id and stores them in the session object. AssetController#index then uses these values to select the data to be displayed and the correct view.

THE PROBLEM I have is that I also need to be able to publish URLs like "http://www.foo.com/assets?user_id=10&tag_id=185&type=video&sort=recent" - for sending by email etc.

The query parameters override any settings stored in the current session. They also need to be sticky otherwise the principle of "navigate away and come back to the same position" is broken. This means that AssetController#index has to merge any query parameters with the current session settings and store the combined result back into the session.

So I now have 2 ways of doing the same thing, which does not seem very DRY.

I don't like the Session having this schizophrenic quality but it certainly simplifies things to be able to use a form for selecting sort order and setting up complex filtering options, etc.

Am I wrong to treat the Session as a resource to be POSTed to? I would be grateful for any guidance you can give me.

Answer 1

Theoretically speaking you're quite right. REST has the stateless constraint explained here by Fielding (The "inventor" of REST). In facts if you wanted to stick with his REST proposal, you should have no "sticky" options at all. Which means that the parameters have to be passed at every request and not retrieved from a session object, this way you would have a consistent approach in the two cases your describing.

Answer 2

Another, stateless, way I could see of doing this is to generate a key for these map locations and store them in some persistent store on the server-side. The current user's could be a row and then if they were to go to a different URL that represents some other location then you can merge the two rows from the DB and then create a new key and send them to that URL (am I making sense?). The stateless aspect just means you can't store things client side (like cookies/sessions) - it doesn't mean that client actions can't change server state for future requests.