[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: REST as RPC done right
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|