[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: REST as RPC done right


rest methods
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.