Via Savas, I noticed a good post from Eric Newcomer;

The doc/literal style would seem to be the most abstract or the most “loosely coupled,” since it does not include data typing (although data typing is provided by an associated XML Schema) and does not include a method name in the message.

Wow, I’ve been saying exactly that – “not include a method in the message” - for years now. Good to see Eric on board! 8-)

But unfortunately that’s not the whole story. For the kind of loose coupling that folks really seem to want, simply removing the method from the message isn’t sufficient. The method has to be removed, as Don Box would say, from the contract. Or, put another way, give all services the same contract (trust me, it’s true, and it’s worth spending considerable time understanding why)

Another way – a software architectural way – of looking at this, is to ask what the different architectural constraints are at work between a message without the method in the body while still having service-specific contracts/interfaces, and an architectural style where all contracts/interfaces are the same. If you can’t find an architectural explanation for the loose coupling, then it’s not there. I’ve mused about this recently.

And there you have it, the principle difference between SOA and REST, and the reason why I’ve also been saying that REST is what Web services folks have been looking for all along.