Mark Nottingham responds to my suggestion that “REST = SOA + late binding”;
[…] While I see the truth in this, I think it’s pretty orthogonal, and it’s not that compelling for most SOAish folks. This is because their use cases are machines talking to machines, not people talking to machines. In Web browsing, this is great, because people are smart enough to look at the late-bound semantics in a representation and figure out what they want to do; machines aren’t, yet.
Hmm, I think we might not be in synch about “late binding”. Without getting into the nitty gritty of it, which I admit eludes me sometimes, perhaps we can just look at the use Roy makes of the term;
This abstract definition of a resource enables key features of the Web architecture. […] it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request.
“Late binding of the reference to a representation” refers to GET; that any reference can be turned into data without dependencies on any centralized component. As a comparison between the SOA and REST approach, consider an identifier for a purchase order; REST would use a URI, “http://example.org/po/928340823”, whereas an SOA approach might use just “928340823”. Turning the former identifier into data, no matter where its discovered, requires simply invoking GET on it. Turning the latter into data cannot be done without a dependency on some central component that turns purchase order identifiers into data. This is why Web services need centralized registries like UDDI.
Hopefully this sheds some additional light on what “REST = SOA + late binding” means. Another interpretation could be “REST = decentralized SOA”.