Doug, anticipating my response, promptly responds.

He brings up the “identification vs. location” issue, which I agree remains a point of contention between many (though the Web wizards are all in agreement on this one, at least 8-). But we’ve already been there, and I don’t think I could explain my position much better than I did there. So I’ll concede that point for the moment so we can move on to an aspect of architecture which I feel is more important in determining the degree of loose coupling; late binding.

REST uses late binding, as REST clients are developed to a system-wide abstraction; the resource. As an example of what this enables, a RESTful client can get data from any RESTful server. SOA cannot do this; a constrained interface is required for this, whether in a RESTful manner or not.

FWIW, in these terms, one can look at REST as the natural evolution of SOAs on the Internet; SOA + late binding => REST

Another excellent piece by Adam, this time on disconnected operation. He writes;

This model is profoundly different than the normal browser.

Well, different, but not “profoundly” different. But keep in mind that REST is more than just what is seen through a browser. It’s simply data transfer.

What he describes there is an architecture which sounds an awful lot like REST and “REST + additional constraints” to me, where the additional constraints would include things like resources are queues. Obviously not all resources would be queues in the system Adam describes, which is why you’d need two styles; vanilla REST, as well as REST with the queue constraint.

Doug Kaye writes, in reference to a list which places REST before SOA;

It also tracks the scales of tight-to-loose coupling and the availability of supporting technologies.

(suggesting that SOA is more loosely coupled than REST)

I don’t have much of a feel about how loosely coupled “Orchestration” is, but I do know that REST based services are more loosely coupled than SOAs. Whether or not you believe that REST can be used for machine-to-machine communications, I think it’s pretty clear that REST uses late binding, while SOAs do not, since REST constrains the interface. Amoungst other things, this means that any agent can exchange data with any service, past, present, or future. You can’t do that with SOA, because you don’t know the interface that future services might use to exchange data.

An interesting question would be, what would a late bound version of an SOA look like? And wouldn’t this be worth pursuing?