SOAP vs. REST - Even More Comments
Mike Glendinning writes comments that are longer and more elaborate than most of my blog entries — check it out here. (You should get a blog, Mike.) I’ll try to address some of his points here:
What is SOAP? I agree that “REST vs. SOAP” is basically just a wrong comparison; still, in a pars-pro-toto way, SOAP simply stands in for the WSDL+SOAP+some transport protocol+lots of extensions stack. It’s technically wrong, but OK for the purpose. (I’m the first to admit I changed my mind on this.)
What is REST? Mike argues there’s no clear definition; I beg to differ. I find the REST definition in Fielding’s thesis much more concise and detailed than any SOA definition I’ve seen so far, including my own. And as I’ve pointed out before, the REST folks don’t argue very much with each other when they’re questioned whether something is to be considered RESTful or not.
REST is RPC — no, it’s not. Request/Response and RPC are different beasts. RPC aims to turn a network interaction into an implementation detail by means of proxies (stubs and skeletons). Request/Response is simply a (very common) communication pattern.
HTTP more complex than SOAP — I have to agree with Robert’s comment: if you simply take SOAP, especially 1.2 (which is a pretty good spec), it may be less complex; if you consider the contents and the value of HTTP, you’d have to map it to e.g. WS-RF (shudder).
Tim Bray has picked up on the debate, as have Mike Champion (again) and Steve Loughran. Fun and entertainment, as usual …