Hmm, so if, as Anthony Hanson wrote, “Great Burgundy smells of shit”, do I have to head over to the nearest barnyard to refill this thing? I’m guessing that this will never place a trip to Nuits St. Georges.
(link) [Mark Baker’s Bookmarks]
“Why is SOA likely to succeed where CORBA failed?” – I wish somebody would answer that for me in software architectural terms.
(link) [Mark Baker’s Bookmarks]
Oops, good catch Patrick. Yes, an unsafe GET isn’t good (though your explanation seems to be describing idempotency of GET which is a side effect of safety).
(link) [Mark Baker’s Bookmarks]
Note to self; write an article on how Internet media types, namespaces, must-ignore and must-understand conspire to provide a 97% solution to the document versioning problem
(link) [Mark Baker’s Bookmarks]
Yes folks, it’s really that simple. Document exchange as state transfer; accept no substitute.
(link) [Mark Baker’s Bookmarks]
Mark Baker, poster boy for the TAG’s httpRange-14 issue. How’s that for Google-gaming? 8-)
(link) [Mark Baker’s Bookmarks]
Via Dave Orchard. LOL! I haven’t laughed this hard in a while.
(link) [Mark Baker’s Bookmarks]

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.

Fight! 8-)
(link) [Mark Baker’s Bookmarks]
“The Semantic Web is for connecting things”
(link) [Mark Baker’s Bookmarks]