Someone (Mark Twain?) said "To a man with a hammer, everything looks
like a nail.".
Lots of people now have XML shaped hammers out there. I get the sense
that some of them are tapping those hammers into the palms of their
hands, contemplating swinging in the direction of the HTTP protocol.
I don't know how I feel about it yet. I'm just like that rabbit, caught
in the headlights of the oncoming juggernaut. I'm too engrossed in
observing the spectacle to do much about it at the moment. Here is the
thought process that I believe is taking place.
HTTP is a protocol. A protocol is essentially a set of statements that
can be sent to and fro in some well-defined order to achieve some
result. In order to be easily understood by the parties involved in the
protocol exchange, each statement is expressed in plain text and in a
highly structured form. Statements have a small number of top-level
types -- GET, POST, PUT and so on. Statements all share the same basic
form -- a header that consists of name, value pairs and an optional
body....
Now, re-read the previous paragraph having mentally substituted the word
"statement" with the word "document".
Did that get your XML hammer twitching? Lets keep going. An XML document
corresponding to the HTTP protocol concept of a GET request for the home
page of propylon.com might look like this:
<http type="get" version="1.1" url="propylon.com">
<header>
<Accept>text/html</Referrer>
</header>
</http>
So, what is wrong with this picture? Well, in terms of theory I suspect
all is well. I don't see any insurmountable problems in re-casting HTTP
as say, XML-HTTP. In theory, it would actually make life easier I guess.
It would allow Web proxies and other sorts of intermediaries to route
and process content in clever ways beyond the simple header processing
currently possible. It has the intellectually satisfying appeal of a
unified syntax....
In practical terms of course, large amounts of Web infrastructure
software expect HTTP headers to appear the way TBL designed them in the
first place. Today's proxies and routers would take a dim view of an
XMLised HTTP.
However, we may be able to get chocolate on both sides of this
particular biscuit. How about this?
POST propylon.com 1.1
http-accept: text/html
<http type = "get" version="1.0" url="propylon.com">
<header>
<Accept>text/html</Referer>
</header>
</http>
This approach purposely mirrors some of the key syntax from the legacy
(!!!) HTTP protocol but keeps the normative version of the protocol
statement/document in the payload/XML. Interesting.
This reminds me of something...what is it I wonder? Ah! I remember SOAP!
Everything is an, um, POST request. Everything is in the XML encoded
payload. SOAP headers are the moral equivalent of HTTP's headers.
But why stop there? We could apply the same logic (if "logic" is not too
strong a word) to other statement-oriented protocols like FTP, SMTP,
POP3, IMAP4, and NNTP?
Come to think of it, where does that leave some of the newer protocols
that have sprung up in recent times? What about Jabber, which uses an
XML statement language? What about WebDav, which uses an XML-based
statement language?
Frankly, I don't know, but there does seem to be, shall we say, room for
consolidation. I also detect room for some interesting commercial
maneuvering -- especially around SOAP as a mega-hammer with which to
strike a blow.
Like I say, I'm just the rabbit in the headlights of the oncoming
juggernaut. Gee! Look at those pretty bright lights....
