Originally Posted by lastcraftA frameset is a good example of a client holding it's own state. Frames do have many usability issues when used for normal websites, so I would only use them when I want to simulate a GUI application - like a mail client - inside a browser.Now I really don't understand . You would need frames or some such to maintain state as otherwise the whole thing will be blown away by the next request.
REST is about transferring resource representations. A representation can be plain text, an image, a 'static' HTML page, but also an interactive view written in Flash or using 'DHTML'.Also I thought REST was about not shipping app. code (like applets) to the browser, just document formats.
In a REST based application, server and client are responsible for their own issues. It's seperation of concerns. The server is responsible for keeping state of it's resources. The client is resposible for keeping state of it's user interface. This means that to achieve the same functionality as what you can do with sessions in PHP, you need a heavier client.Now I know programs are just data, but it seems you are taking the complexity out of the server architecture and just moving the whole lot into a massively complex document.
I used to think that web applications should be implemented using static HTML and keeping all functionality on the server, so I can understand how you feel. It's quite a mindshift.
And please don't get me wrong: I will never say that it's easy to make such a seperation. It's in some way comparable to OO design; deciding which party does what.