Bzzzt; thank you for playing our game...

We have some wonderful parting gifts for you.

In his quixotic attempt to prove that of two disparate things one is better than the other, Carlos writes (emphasis mine):

Push based messaging is more tightly coupled because it is the responsibility of the producer to know how to push messages to its consumers. This puts the onus on a single producer supporting the requirements of all its consumers, a highly impractical proposition. The standard solution is to standardize the push infrastructure (see SMTP) placing stringent requirements on all consumers to comply with that infrastructure. Consumers are required to be constantly available and continually upgradeable to function properly in a push network. Sean McGrath has a paper that highlights the pros and cons in more significant detail.

SMTP is a protocol specification, just like HTTP, the closest thing we have to a manifestation of REST. It is not an "infrastructure", which implies implementation.

Later on in the missive he writes (emphasis mine):

An example of asychronous publish and subscribe implemented in RESTful fashion is the ad-hoc RSS network. Let's compare RSS a polled¹ pull asynchronous model versus SMTP a pushed asynchronous model. The common explanation why email spam is difficult to fix because the SMTP has no mechanism to authenticate the source of the email message. However, the problem lies deeper than that, because SMTP is a push network, for it to function correctly, all the nodes of the network need to be upgraded in unison. Furthermore, message propagation are initiated by the source and not by the consumer it becomes more difficult to avoid spoofing.

...

1. Because HTTP does not have a built-in asynchronous delivery mechanism (see Rohit's Dissertation), polling is used.

The funny thing about this statement is that I don't seem to recall the day back in 2001 when all the world's deployed SMTP infrastructure had to be simultaneously upgraded in a "big bang" uber-coordinated systems management nightmare because the RFC that defined the SMTP protocol was obsoleted by its successor.

This argument has nothing at all to do with either SOAP v REST, or push v pull, and everything to do with how to effectively design a protocol that embraces support for forwards- and backwards- compatibility of future revisions and/or extensions; something that is certainly important in any protocol design, but not relevant to the "argument" that REST is better than SOAP, which again is just silly.

He continues (emphasis mine):

The push and pull methods both fail if the consumer isn't informed of a change in the producer. The difference however is this, which party holds the responsibility for ensuring compatibility? In general the initiating party holds responsibility. That is the initiating party makes the decision as to what is the most compatible access path. Also, in general there are more client implementations than server implementations, therefore it is less demanding a task for a client implementation to upgrade than a server. From a global perspective the amount of effort is identical, however at the local level (where it really counts) the effort differs significantly. Therefore a pull based implementation has a greater chance of ensuring compatibility.

Not quite. Again, this has nothing to do with push v pull but in the design of the protocol and its binding to a transport layer. Just because HTTP is a client-initiated request-response protocol does not mean that the session over which a "pull" will be performed need necessarily be initiated by the client nor that a push be initiated by the source. One could design an application protocol over BEEP which would allow either party to initiate the session, regardless of which will be doing the pulling or pushing.

I have no idea what is meant by the statement: "That is the initiating party makes the decision as to what is the most compatible access path". As to the statement that there are more clients than servers, I would only point out that there is more to IT than "clients" and "servers". C/S is so early '90s:-) There's also peer-to-peer interaction to be considered amongst other styles of interaction.

As to the conclusion drawn, that a pull-based approach has a greater chance of ensuring compatibility, I don't see a proof. I see a non sequitur.

He wraps up with this (again, emphasis mine):

In otherwords, the URI is not just an REST idiosyncrasy that can be ignored as the SOAP proponents have done.

<scratches head/> Huh? WTF are this and this? Once again, so-called "SOAP proponents" are unfairly characterized as being somehow anti-REST which is simply just not the case.

To assert that REST is better than SOAP because you can do things asynchronously with REST is an absurd argument. Nothing precludes doing things asynchronously with SOAP, or using SOAP in a RESTful manner.