Thinking more about post on continuation-based frameworks, and reading through this interesting conversation, it occurs to me that RESTful encapsulation is being limited to one request, stateless, and pushing a lot of data into one HTTP call. I think this is too limiting. Encapsulation is nice, but if you are willing to give up synchronous completion of the encapsulated activity, then multiple requests aren't so bad.

The example that came up in that conversation is an ecommerce site. In that model, the product pages can and probably should be RESTish. But the ordering process isn't so much. There's multiple steps. A variable number of steps probably, and sometimes you have to go back a step (e.g., invalid credit card). It's interactive, and highly stateful. Not very REST, maybe good for continuations.

Well, lets pick that apart some more. The items you purchase are all RESTy. Everyone sees the same items.

The shopping cart is pretty easy to imagine in a REST form. You pop things in, you pop things out.

OK, so the user hits "checkout", and you grab the cart contents from the REST cart. And you grab the HTML representation of the contents from the cart. And then you have an "app" that lets you see the total, remove things, etc. Is that app REST? No... I don't even know exactly what that would mean if it was REST. This is where I think people can go down the cargo cult path, because they are looking at how to make that RESTy, and so they worry about what the URI for the delete action looks like.

But if you step back just a bit, that app can look RESTish too. You tell the app where the cart is. You tell the app what to do when you are finished. Then the app is a service; when you send the user's browser over to the app, you are calling that service, and you'll get your response when the app directs the user's browser to the next step in the process.

Unlike what is typically described as a service, attaining the result -- an actual checkout -- takes many requests, not one. And it involved the user's browser. But it can be encapsulated. So can the payment, and other pieces. Is the result going to be as tweaked out as Amazon's checkout form? Probably not; the application boundaries might be quite noticeable to users (though there is progress to be made there, and Ajax techniques can help a great deal). The user might not be able to edit all the pieces at once. There's probably a bunch of glue; glue is overhead, RESTful or not.

And that form/app for actually managing your shopping cart contents? Yeah, that can be continuation based. But why? It's not a complex application, you don't need a clever framework. Once you have a clever framework you're going to mix these problems together and solve them all at once, because you have to justify the framework, and there's no way in hell you can do that for some silly little form that lets you change what's in your cart.

Maybe there needs to be some language for non-service-oriented REST; REST where the browser is a peer, not just a viewer into the consolidation of services on the server side. Or another term, maybe "REST" shouldn't be overloaded so much. But something... browser-based web services?