Phil Windley expresses an interest in tuple spaces and points to an item that spells out in some detail why I am still unsure of what ReST really means at a deep semantic, implementation, and performance level. I wrote about this in a couple of (admittedly superficial and this is more of the same) items in April 2003.
Whether using "pure" HTTP, or SOAP, XML-RPC, or Jabber, (or SOAP over Jabber, XML-RPC over SMTP, SOAP over BEEP over HTTP, or... even RSS, RSS-Data, and polling or cloud APIs as part of the transport) the key is to distinguish transports from actions.
A tuple space (or XML space, where the tuples are represented as XML text) for distributed, asynchronous computing can be (and should be) implemented on top of multiple transports. The important aspect for applications are the actions (tuple space semantics). The implementation and performance of the transports can (and should) evolve independent of the simple semantics of tuple space actions.
Above the simple actions, independent of the transport implementations, the simple tuple space actions can be combined into various kinds of databases, queues, exchanges and marketplaces that we really want to focus on evolving in the first place.