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
