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.

[Emphasis mine.]  Hmmm. I was thinking that the contract is explicit (for purists or pragmatists). Of course, I don't work for a research firm, so there you go.

"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.

Comments

[kevin]

I know! We could do a customer administration app! The SOAP version could have getThis, getThat, and updateTheOther methods. And in the REST version the customers could be resources with well-defined GETable and POSTable representations. Oh never mind, that wouldn't be enterprisey enough...

Seriously though, I've used the "solving it twice" thought experiment enough to get comfortable thinking RESTfully.