Web Things, by Mark Baker

Clemens writes some moreabout HTTP, transactions, reliability, despite his publication deadline. Go, Clemens!

FWIW, I don’t disagree that this is a commonly held view, but in my view, it’s entirely incorrect. HTTP is not a panacea, but it’s also not just a web page retrieval protocol. Some point-by-point responses;

• I said that HTTP, without resorting to things like tunneling or callbacks, doesn’t support any flavor of transactional behavior[…]. This is incorrect. HTTP supports what is sometimes referred to as a “state alignment transaction”. That is, any party in the transaction can synchronize with the state of the other party using HTTP GET. State alignment is a form of transactional style that fits very well with the Internet/Web. Obviously, just using GET isn’t sufficient for all transactional needs, even with a state alignment approach, so more work remains to be done. But to suggest that HTTP doesn’t and can’t do transactions is false.
• For additional cases where HTTP doesn’t really work (P2P in general and even non-transactional, long running operations)[…]. I use HTTP for P2P on a daily basis. My company’s HTTP routing platform is premised on the fact that HTTP is suitable for P2P, and we’ve built some really cool, useful, and scalable stuff with it. Ask KnowNow about this too. WRT long running operations, see above re state alignment; you just have to look at the problem differently.
• I can’t say that I understand what you mean by the TIP/BEEP/HTTP pictures, but the prose preceding it suggests that you didn’t understand my point that you quoted. I see reliability as an application layer issue, not a transport one. See what Jim Waldo has to say about the topic (chapter 5, if you don’t have time to read the whole thing).