[
Lists Home |
Date Index |
Thread Index
]
On Thu, 2002-02-28 at 15:08, Paul Prescod wrote:
> I'll pick the nits that Mark wouldn't. It isn't that REST methods are
> more generic, it's that they _are_ *generic*. If a method doesn't make
> sense for most or all resources then it shouldn't be a REST method.
Being generic does not absolve them of being methods.
> > ... URIs are not a magic wand for cleaning up
> > architectures in my experience either.
>
> That's a little too vague for me to be able to say much about it.
That's precisely what I'd say about URIs!
> > From my perspective (XMLChucker etc.), REST still looks like RPC.
>
> >From my perspective, XMLChucker looks like RPC. ;)
Except that there is no return value. Chucking is just chucking. If
someone chucks back, good for them.
> REST requires the generic intent of the message to be available in a
> manner that is visible in the protocol and thus to intermediaries. RPCs
> do not and as far as you have described, XMLChucker does not. So to me,
> XMLChucker is more like an RPC protocol. (assuming it allows return
> results, which it may not)
The intent of the message may be visible from the contents of the
message. And no, XMLChucker doesn't return anything. (Or won't,
anyway.)
> In my mind, the defining characteristics of RPC are a) a single
> endpoint supports an arbitrary number of methods b) the endpoint is
> allowed to invent its own methods and c) the endpoint returns values
> based on the method name and method inputs.
In my mind, the defining characteristic of RPC is that it is Remote
Procedure Calls, passing parameters to named methods and expecting a
result. Your (a) and (b) strike me as nifty extra features, not
something fundamental.
> If HTTP is RPC then I would say FTP is also. HTTP calls them "methods",
> FTP calls them "commands" but the important thing is that they are
> defined *in the standard* (modulo extensions) rather than being defined
> by the end-points.
HTTP is an RPC application built on TCP/IP. The fact that the method
calls are defined *in the standard* doesn't change much about that, and
HTTP certainly allows for extensible parameters in any case.
I can certainly define standard non-extensible protocols which happen to
use XML-RPC or SOAP.
> And it is because they are defined in the standard that intermediaries
> have a hope of understanding them.
Intermediaries have a chance of understanding the wrappers. We don't
seem to write many intermediaries which have a chance of understanding
the contents, but that hardly means it isn't possible, especially as the
costs of processing continue to drop.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
