This kind of simple HTTP based approach is definitely showing a lot of promise. It significantly simplifies scaling (look at Amazon's S3 service) but still leaves the difficult problem of maintaining transactional integrity -- which is inherently difficult to scale -- for the active part of your site.
We need to develop architectures that give us the easy scalability of simple HTTP for the majority of our requests while minimising that which is reliant on hard to scale transactional systems. The alternative is ever larger monolithic databases. Perhaps we can learn from Google. http://labs.google.com/papers/bigtable-osdi06.pdf
Somewhat interestingly, WebDAV has this idea of combining multiple requests (in an XML wrapper). The intention there is to do the entire set of requests in a transactional fashion. If you just have a way of referring to a transactional context, you could then explode that multirequest into a set of normal requests. This doesn't work across multiple backends (without, I suppose, some fancy transactional event system), but at least it offers transactions on some compound structures. (I've actually been thinking about this a lot as it relates to OHM, as it's kind of an outstanding issue there.)
The other approach is to be sloppy, and to be ready to deal with situations where the consistency of the system has been compromised. This is much more practical when you don't control all the pieces. Actually, it's about the only thing that is practical when you don't control all the pieces.# Ian Bicking