Mark Baker says: For many years, people have talked about normal ACID/2PC transaction semantics are unsuitable for use on the Internet. That is still the case. We need to rethink what a transaction is on the Web, and I can guarantee you that when we do, it will be implementable as an HTTP extension.
I think that this sort of rethinking has long been done for implementing asynchronously decoupled systems like EDI VANs and SWIFT. A great way to achieve transactional behavior and failure recovery in distributed systems are serial, partially overlapping transactions and sagas. The recovery stategy is compensation. That's in line with the document Mark is pointing to; let's look at this for HTTP.
2PC, E3PC and X3PC require two-way connectivity and have "connection loss" as one of their core functional protocol properties to initiate recovery or abort. This makes them incompatible with HTTP, since connection loss is an intentional feature of HTTP. The pillar of saga approach is reliable, guaranteed, at least once (and better exactly once) delivery that explicitly fulfills ACID property "D". Since Sagas are propagated using a single message (otherwise you'd need 2PC), the ACI properties are implied.
Problem: HTTP is a one-way request, response mechanism that cannot guarantee reliable delivery either way. The responding party has no knowledge whether a response to GET (a) arrived in full and (b) was successfully made durable by the requesting party. The requesting party has no knowledge whether a PUT/POST/DELETE request was understood and made durable in case the connection breaks while the response is being relayed. The lack of reliability of HTTP motivated IBM's HTTPR and Microsoft's receipt based SRMP that's part of the BizTalk Framework. So, can such reliable messaging and hence compensation based transactions work over HTTP? It seems so.
Looking at these things more closely, you'll see that HTTPR is REST incompatible, because All HTTPR exchanges are carried as an HTTP POST request payload and its response. While the name implies that it is closely related to HTTP, it's indeed a rather complex tunneling protocol. The actual weak spot of HTTPR is that exchanges require a high degree of coordination and by it's reconnect strategy, exchanges can jump from one connection to another and clients may start panicking at their leisure (this invites DoS attacks). HTTPR reminds me a bit of the things that James Snell and I did when we were toying with SOAP-CTX.
The BizTalk Framework approach is a bit more friendly to look at, because it requires only baseline HTTP. The catch is that SRMP requires two-way connectivity of some sort, because it relies on receipts that must be sent by the responding party (that's the request receiver; responding party in the sense of HTTP). The receipt may be sent through any transport of your choice, actually. It also requires quite a bit of management to for managing retries and holding on to message-ids for discarding duplicate requests. If the request party sits behind a firewall, the responding party can't send a receipt by means of HTTP.
So, while both are using HTTP to implement reliable messaging, HTTPR does so by tunneling and SRMP does so by callback and two-way connectivity and hence I don't think either is REST compatible. The sole purpose of both protocols is clearly to (ab-)use the HTTP infrastructure (ports 80,443 in particular) to get through corporate firewalls. I do think that the required effort of both approaches and the introduced complexity to achieve reliable delivery shows that HTTP as a protocol by itself is just not suitable for all and every purpose; even not for reliable delivery of arbitrary data streams. Implementing reliable messaging by other means is comparatively trivial.
I really want to stay out of this REST discussion, but I think that suggesting to use HTTP for everything anytime doesn't make much sense and is technically questionnable.Whether SOAP on HTTP for data exchanges not requiring a high degree of reliability should be RESTful or not is a wholly different story and I'll be happy with any consensus reached.