The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Threaded View

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