XML-RPC and http

[Mark Baker]

Clay Shirky wrote:
> 
> > It also has other more specific get methods such as
> > manila.editors.getStoriesHeaders, and manila.editors.getTable.  These
> > can also use HTTP GET, just on different URLs, e.g. GET /StoriesHeaders,
> > GET /Table.
> 
> Yes, that works, but do you see how you are asking me to worry about
> three different containers for my desired interaction?
> 
> 1. What is the file-system abstraction? (e.g. /StoriesHeaders)
> 2. What is the content of the message?  (e.g. ?author=clay&subject=XML)
> 3. Which http method should I use? (e.g. GET, PUT, HEAD, DELETE)

I'm not sure I follow.  Identifying resources, and then executing HTTP
methods on them, is how the Web works.

> Note that #1 and #2 are guaranteed to be non-standard and unparseable
> for validity of content.

> Meanwhile, XML-RPC says "http PUT is the data transmission mechanism,

POST, not PUT.

> so that programmers can put all the instructions/data/meta-data in one
> package, *and* they get the rich chocolatey goodness of XML as Added
> Flavor Bonus<tm>."

SOAP has two uses.  One is for RPC, one isn't.  You can get all that
goodness from XML without doing RPC.

> Single container + More rigor == Win, from where I sit.

It's a single "container" requiring the same information to do its job
than is required in my example above.

> > So then you have to wonder why not just use the HTTP methods instead of
> > your own private RPC methods.
> 
> This seems to me to reverse the situation.
> 
> The RPC methods are both published and verifiable. http+urls, on the
> other hand, puts two of the three tools for encoding information --
> (virtual) file system organization and name=value pairs -- squarely in
> the hands of individual programmers and their invariably idiosyncratic
> implementations.

We're not talking about RPC vs. http+urls, we're talking RPC vs. HTTP.
RPC defines methods such as "getMyGoat()", "getYourGoat()",
"getHerGoat()".
HTTP defines a GET method that can be used to GET anybody's goat.
And yes, you still need /myGoat, /yourGoat, and /herGoat, but given that
goats are God's creatures, they should probably have their own web page
anyhow. 8-/

> I'd ask the question "If you are going to be sending data to a remote
> machine for processing, why would you do an http one off, when you get
> the advantages of XML if you adopt XML-RPC?"

If you want the advantages of XML, use the non-RPC use of SOAP.  In this
use, SOAP doesn't attempt to overtake the application semantics of the
protocol it lives atop (HTTP in this case).  With RPC, the semantics of
the protocol beneath is ignored.

> 
> > Less than you'd expect, because HTTP's application semantics (the
> > meaning of "GET", "POST", "PUT" are so darned generic).
> 
> So are TCP/IP's.

TCP/IP is not an application protocol, so it can't have application
semantics.

> Suggesting that everything you can do with XML-RPC you
> can also do with http is not only not a criticism of RPC, it isn't
> even an observation about http. Its an observation of the way the net
> works.
> 
> The layer beneath _any_ encapsulation _always_ offers more generic
> primitives. If this were A Bad Thing, SQL would never have won over
> databases tied directly to filesystem primitives, and we'd regard the
> C compiler as a crutch.

Very true.  But I'm not talking about any layer, I'm talking about the
application layer.

> Nope. I cannot replace RPC with http alone.

Try it, you'd be surprised.

> I must also work out
> formats for the filesystem and encapsulated data, whether in a
> query-string or PUTed data.

The query-string has a format; name/value pairs.

> I think your argument is:
> 
>   "http methods + file system + name=value pairs" provides the raw
>   materials to accomplish everything you would want to do with
>   XML-RPC. XML-RPC may offer conceptual simplicity by gathering all
>   desired functions into a single place, as well as the opportunity
>   for more rigorous presentation of the data, but these putative
>   advantages do not outweigh Disadvantages X, Y and Z.
> 
> What I still don't understand is what you think X, Y and Z are?
> Latency? Wasted disk space? XML is overkill? What am I missing?

That's not my argument at all.  See the goat comment above.

MB