Ron over at ZapThink says:
The real challenge to applying REST as a means to implement loosely-coupled Services is that REST has no explicit contract to define behavior, which means that all behaviors are implied. In REST, the data pumped through a GET, PUT, or POST operation contain all the semantics necessary to understand how a Service behaves.
Therefore, REST isn’t appropriate for organizations that wish to take a contract-first development approach aimed at maximizing reuse and composition, in addition to loose coupling. And that’s the rub with REST – SOA aims to reuse not just the resource, but also the operation and the composition as well.
"Data pumped." He makes it sound as if the data is encoded with the application semantics and is merely being "tunneled" over HTTP rather than the application is using HTTP to broker the application state. Oh wait, but isn't that SOAP? File under 'M' for misunderstanding. Ron, here's a suggestion for some research. Pick a problem worthy of a services and/or restful solution. Solve it twice, once with REST and once with WS-splat. Hire some high-priced consultants to help you get each "right," if necessary. Publish the results. Boy, now that would be nice.