Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
