Manage view state with multiple combined REST resources

Say for example I would write a forum which would look like this in the browser:

- original post
  - Re: original post 
    - Re^2: original post
    - Re^2: original post
  + Re: original post
_______________________________________________________________________________

Text of the selected post.

The tree view would be one resource, the text of the selected post would be one and the surrounding page would be one. If another post is selected the hole page should be updated to always display correct URIs in the browser. But if the hole page 开发者_如何学Cis updated the client state of the tree gets lost. The tree resource is reloaded and the information what nodes are expanded, how far I scrolled and the like is lost.

What is the REST way to solve this?

• Use URIs like http://some.where/post/123#someTreeInfo and perform only partial updates of the page? The tree info part could become quite large.
• Construct a complete resource and hide the fact that there are underlying resource like the tree? But that wouldn't save the tree state.
• Transfer the current view state to server and get it back with the response?
• Use cookies?
• Wait for HTML 5?

Other ideas? Recommendations?

If it has a URI, it is a resource. As such, your page containing all this content is a resource, full stop, in ReST and in plain old HTTP. As such it has a life on its own, independent of what you may use on the server to compose your page.

If however you want to serve your page and use ajax calls to update content, then you would go straight to each of the resources you mentioned to get their current version. At that stage, you can use the hash tag (as in your first bullet point) to make the URI copy-paste friendly. Or you can use a hidden iframe to enable navigation to still function correctly in the browser. Both are usually used in combination. In that case, the current state of the page is either (or both) in javascript or (and) in the hash part of your URI.

Note that the page itself is still an independent resource, and as such any view "state" that you would pass around before the hash will create a new URI. Unless you specify Content-Location judiciously, proxies and caches will see them as different resources entirely.

In the scenario where you process all the UI on the server before generating your markup, relying on cookies is simply evil. It breaks the architecture of the web, breaks caching, etc. If you want to use it as a persistence storage with javascript, and as long as the server doesn't look at it, and it's purely cosmetic, then help yourself.

In that sense, local storage in html 5 will solve the same problematic with more space.