Quote Originally Posted by lastcraft
@meryn -- The reason I kept a timed "login" was to keep it the clients stateless. How does my plan above contradict REST? I am sure it does, but I could not see how. Relying on HTTP authentication is too limiting and I didn't see how it was enforced by REST other than philosophically.
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.
A 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.

As I said, you can use cookies to maintain client state over multiple requests. The server should't touch the cookie though.

Also I thought REST was about not shipping app. code (like applets) to the browser, just document formats.
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'.

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.
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.

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.