The REST vs SOAP permathread has reared its ugly head again, instigated by a post by Don Box.
Stefan has possibly the most compelling comment:
I do believe that on a very high level, the debate is utterly irrelevant.Indeed. Most of the so-called debate over REST vs SOAP is largely uninformed and hence, irrelevant (other than the fact that it serves to keep people very confused, which is a problem that is very relevant).
However, Stefan surprises me with this one, in comments to his own post:
But even then, lets take reliable messaging as an example. I dont know it extremely well, but I wrote an article about it a while back, and I guess I understand enough of it. I still have not been able to come up with a good scenario of where I would actually deploy it.As one of the authors of the WS-ReliableMessaging spec, I think I know a thing or two about it and its potential uses. A classic use case is b2b messaging between business partners where the messages absolutely, positively must be delivered or else the business suffers. We've been working with some automotive partners and they have clear and unambiguous requirements for reliable delivery of messages in the automotive supply-chain. Last time I checked, the automotive manufacturers (heck, any manufacturer for that matter) considered their supply-chain to be a pretty big deal. You don't want to find out that a purchase order wasn't received by your supply-chain partner when your manufacturing line is sitting idle because a parts shipment hasn't arrived because the purchase order that authorized their shipment was never received by your supplier... by then, it is too late, you've already started to lose money.
Could one accomplish reliable delivery using purely RESTful interactions (e.g. using HTTP in all its glory)? Of course, but that is not the point.
With all due respect to Bill de hOra, the HTTPLR spec defines an aplication of HTTP to achive reliable delivery of message content that isn't as efficient as the WS-ReliableMessaging protocol. The fact that each message has to be individually acknowledged could prove problematic from a performance perspective, as it may require that acknowledgements be retransmitted in the event of failure. This is not the case with WS-ReliableMessaging.
Additionally, for certain failure cases, the source needs to retransmit the message, even though it may have already been received. For very large messages, this could present an unnecessary performance penalty. Again, this is not the case with WS-ReliableMessaging.
Sometimes, little things, such as performance, factor heavily into one's architectural decision-making.
You will also note that the HTTPLR spec provides for two modes of operation; one that leverages the PUT and DELETE HTTP methods, and one that leverages POST. When I asked Bill why, his response was, as expected, that many implementations of HTTP simply don't support (client) or allow (server) these methods. He didn't like the fact that he had to provide a POST alternative, but the cold hard reality of the state of HTTP implementations and deployments required that he do so. That doesn't bode well for interoperability, as we all know that choice in a specification is the bane of interoperability.
Stefan also comments :
Ive not seen any real-world deployment of any of the more advanced WS-* standards yet, and I have serious doubts that transactions or reliable messaging will be widely deployed soon.I will concede that it is taking longer than I might like to drive the WS-* specifications through the standards process. However, the reality is that standards take time to mature and vendors rarely implement until the standard is established (either de facto or de jure) and the market pressures are brought to bear.
While Stefan doubts that transactions or reliable messaging will be deployed soon, the reality is that most vendors are actively developing the next generation of Web services capabilites in their offerings and I am confident that reliable messaging will be amongst the advanced WS-* features supported in most vendor offerings over the course of the next year or so. Once a certain threshold of vendor adoption nd interoperability has been achived, then you will see a sharp increase in the number of Web services deployments between, as well as within, enterprises.
I plan on posting a follow-up that addresses other aspects of this debate soon.