Re: [xml-dev] REST as RPC done right

[Paul Prescod <paul@prescod.net>]

Stephen Anderson wrote:
> 
>...
> 
> I believe you are incorrectly characterising what HTTP's 
> request-methods are; IMO, the URI is the method, the 
> request-methods are just different ways of invoking them. Or 
> to put it another way, the request-methods don't do the 
> work, whatever is represented by the URI does, which 
> makes the URI directly analogous to an RPC method 
> (though I guess in the case of SOAP et al they're 
> better characterised as "objects").

So if I do a "GET" of a stock quote and a "PUT" or "POST" of a stock
quote, that's really all the same thing? I disagree. HTTP's request
methods are methods. They are highly generic methods but methods
nevertheless.
 
>...
> > I think RPC on top of HTTP is bad, purely because HTTP is an
> > application. RPC
> > goes beneath it. This is how things should be.
> 
> I have to disagree here. You've already said yourself that 
> HTTP is implictly an RPC protocol: why wrap one RPC protocol 
> in another?

He said you shouldn't. Because the level beneath HTTP is implicitly
already RPC so putting another RPC layer on top makes no sense. Are you
guys in violent agreement?

> I think people are tying themselves into semantic knots here; 
> surely RPC protocols are just a subset of resource-request 
> protocols, more domain-specific. 

The only concept XML-RPC or SOAP RPC has is "send message and get
result." I don't see how that is "more domain specific." You can of
course build domain specific protocols *on top of* RPC protocols. I'm
not familiar with the term "resource-request protocol". I'd use the term
"application protocol."

> Any generalised resource-request protocol like HTTP can be used as 
> an RPC protocol; though of course it does not follow that you 
> _should_ use it :) Then again, sometimes interoperability is 
> worth inefficiency...

You can layer any protocol on any protocol. IP on pigeons!

 Paul Prescod