February 27, 2002
A coworker casually mentioned this article on ZDNet citing a .NET Developer Platform architect from Microsoft who suggested that we look for a replacement for HTTP for web services. I thought it interesting, but nothing terribly new, since yeah HTTP is kinda pushed to the limits with some of the things coming down the pipe. It seemed to be more an article intended for upper management's consumption rather than serious techies'. Before too long, though, I saw a number of irritated comments out there (scottandrew, oreillynet, PHP Everywhere...).
I don't understand this. Am I missing something in the tone of the article? Or are people just reacting to the fact that it's someone from Microsoft who's suggesting another protocol? I thought that debates about the the suitability of HTTP for web services have been going on for a while now. I recall Simon St. Laurent mentioning this almost two years ago. It's discussed in both O'Reilly's XML-RPC book and their SOAP book, which mention other protocols like BXXP, apparently now called BEEP. We have Jabber-RPC, in which XML-RPC messages are being carried over Jabber (not that anyone ever seriously expected that to replace HTTP, it's just damn cool).
So why the uproar? We should think about these things now so we can lay down a decent infrastructure, one that's robust and secure.
Of course, I write this at the same time that I'm designing web services to run over HTTP, probably on port 80. Heh. Nothing that exposes large interfaces to massive, mission-critical systems, though.
Alex Russell has some worthwhile things to say on the matter, as usual.
