OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ 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,

> 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!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS