I'm not sure what my post about RESTFaces has to do with anything Jean-Jacques is talking about, but those are nice pictures.

It seems to me that the "business interface" mentioned is the exchange of well understood document/schema along with well understood operations. In other words you have to define both. So, in a business process where GET and PUT (and friends) apply to *all* business entities and are not just per process defined methods, why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity? What's the actual  limitation induced by applying REST?

Certainly there are document schema for interchange in BPM space, but they seem to be stuck on non-uniform methods, aka operations, as were the WS-* standards before them. One downside of non-uniform (or per process) operations is that you have to worry about the order the operations are executed in, and ultimately that reduces to a programming/scripting exercise, but happening across system boundaries. They also have private semantics unless the language used to derive them is in turn formally defined (ie it's something like Scheme, Prolog, or even KIF). It seems to me those downsides outweigh the advantages, going by technology like WSDL and UDDI.  Perhaps all the SOA/BPM  community are saying is that REST doesn't have a formal interlingua for business processes - but why would it any more than an NFA state machine formalism would? That would be bad layering.