Lambda the Ultimate

This is a very healthy reduction and very RESTful.

The best way to write applications is to keep all the state at the client. That way all communications with the server is static, and can be cached aggresively.

Keeping state at the client is the best way to write content-driven "applications", but any application that is mostly concerned with providing a service, rather than content, is less likely to be easily arRESTed.

This is a very healthy reduction and very RESTful.

The best way to write applications is to keep all the state at the client.

In the REST context, it often needs to be made clear that the above comment refers to session state, rather than e.g. resource state. To relate that to the shopping cart example (and to my earlier comment about orders), there's really nothing fundamentally wrong with the idea of a shopping cart as a server-side resource — that's a decision which may be driven by application requirements.

REST design principles argue that server-side carts are less scalable, but they're not "wrong". Besides, Amazon seems scalable enough, server-side carts and all.

In that case, state is kept at the server, but it can be defined, and implemented, as resource state rather than session state.

(Note that the extant definitions of REST are fuzzy enough that this point may be arguable, but I stand ready to defend it using nothing but common sense. ;)

randallsquared wrote:

Keeping state at the client is the best way to write content-driven "applications", but any application that is mostly concerned with providing a service, rather than content, is less likely to be easily arRESTed.

I think this perception comes from the terminology ambiguity I've just described. I don't know what example you might have in mind, but there are usually reasonable ways to model services using REST. That's not to say there aren't often tradeoffs, of course, as with almost any design decision.

Unfortunately, the single state approach gained dominance very early on in the history of the web with the metaphor of the "shopping cart". This reduced the forward/backward button to navigational transitions rather than state transitions.

People pick on shopping carts because they're a soft target. Try something more critical, like actual orders. After an order is placed, a common application requirement is that the back button should not unplace the order. How do you want to model this?

I'll conjecture that whatever reasonable answer you give, similar logic can be applied to shopping carts. "[Reducing] the forward/backward button to navigational transitions rather than state transition" is an inevitable requirement of even minimally complex applications.

Keeping state in the client has it's own set of problem I guess.

Especially if the state gets large and the client is on a dialup line.

Well storing the whole continuation on the client is only one option -- a more popular option is to store it on the server and give each continuation a unique identifier for the client to reference.

Storing it on the server is the popular option and it's what I do. But then the problem becomes one of garbage collection. Given limited storage space you need to be able to expire and delete unused continuations. So some arbitary time limit is often imposed whereby continuations older than this time are deleted. This time limit can become an important and difficult parameter to tune.

That said I think continuation based web applications are a great idea. With quite a few in commercial use now I can say that for certain classes of applications they make development much easier and the problems like continuation cleanup etc are quite manageable.