XML-RPC and http

[Mark Baker]

Clay,

Clay Shirky wrote:
> 
> OK, so sorry for not following up to the earlier mail, but I didn't
> know this was an issue I cared about til after I'd cleaned out my
> mailbox for the night.
> 
> It seems to me the important ifferences between http and XML-RPC/SOAP
> are rigor, context, and dependencies.
> 
> Rigor: A query-string can be checked for validity only as a
> url-encoded string. It can't be checked for the validity of its
> elements, eg. a NOT NULL requirement. XML, by contrast, is (or should
> be) more of a straitjacket, forcing the sender to rigorously encode
> meta-data in the XML doc.

Sure.  But it's not part of the URL, so if you move the query string,
caches can't distinguish between http://foo.com/bar?id=234 and
http://foo.com/bar?id=345.  ... assuming that's what you meant by "query
string".

> Context: In addition, XML can contain context -- can be
> self-documenting, in other words. In addition to being parseable, XML
> can contain meta-data about the elements themselves.
>
> Dependencies: Finally, XML can nest data, so that if I am sending two
> Zip codes (sender and recipient, say), I can contain the Sender's zip
> in general sender data.

Absolutely.  XML definitely wins out with its strict structure.

> Now I know that http can be made to do all these things --
> http://foo.com/msg?ID_not_null=12345&senders_first_name=clay&...
> but it can't be made to do these things in a way anyone else can
> automatically recognize without my parser.

SOAP - independant of its RPC use - is one way of doing this.

> Checking the validity of an XML document, with anyone's parser, says
> something about content; checking the validity of an http request only
> says something about the form.
> 
> Now I am usually on the 'use the simpler technology' tip, so I find
> myself surprised to be advancing this view, but it seems to me that
> the there is a big enough differnece here to merit adoption of the XML
> format.

Those are pretty good arguments for using XML as syntax for use by
protocols.

But it says *nothing* about why using the XML syntax should necessarily
change the semantics of the protocol, as is done with RPC.  Using SOAP
"properly" (i.e. not RPC) does what you describe above, but XML-RPC and
SOAP RPC is not just saying "use XML", it's saying "use XML and ignore
the application semantics of HTTP".

Check out the Manila XML-RPC interface,
http://www.xmlrpc.com/stories/storyReader$700

In there are several XML-RPC methods called "get" (e.g. manila.css.get,
manila.customPrefs.get, manila.editorialOutline.get).  Now why would you
want to do something that clearly aims to do what an HTTP GET does, over
an HTTP POST?  You lose so much by doing this.  You lose the ability to
use HTTP proxies (say, to have that content cached).  You lose the use
of HTTP authentication (see how those Manila interfaces require a
username and password?).  You are basically starting from scratch with a
new protocol.

MB