Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: REST as RPC done right
 Joshua Allen wrote: > > > > > 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. > > > > Can you name a protocol that bills itself as RPC that lacks features > a) > > and b)? > > > > Well, it all depends on what you are calling the "endpoint". Most > people think of RPC as being "remote procedure call", not "remote > procedures call". If you are defining the endpoint to be the middleware > layer that routes RPCs to the appropriate end-endpoint, then maybe you > have a point. I don't understand what middleware has to do with it. I'll ask the question again: do you know of a protocol that bills itself as RPC where the core method names are predefined in advance by the protocol? Is FTP an RPC protocol? If not, why not? >... > > the case that everything that RPC touches immediately falls apart. > It's > > rather the case that the RPC layer is not a very important or helpful > > layer which is why you can get away without defining it formally. The > > You mean, "not very important or useful ... when passing hypertext > around"? No, in general. FTP works fine without being defined on top of an RPC protocol and its used for non-hypertext data. DNS works fine without being defined on top of an RPC protocol. I don't see how either protocol would be more useful if it were defined on top of an RPC protocol. > > RPC layer only takes on mythic proportions when people start to revel > in > > the ability to invent their own protocols on top of it...and that's > > where interoperability starts to degrade. > > We may be talking about different things, but defining a common format > for people to slap RPCs on top of HTTP rather than having everyone roll > their own formats (including various things that look like XML-RPC, > hidden form fields, URL-munging, etc.) seems to *help* interoperability. Hidden form fields are payloads. The vast majority of XML-RPC is payload definition. Yes, payloads need to be standardized. But most often they will be vertical, not using any SOAP-defined payload. The payloads will most often be XML vocabularies defined by vertical industries like these: http://www.xml.org/xml/registry.jsp URL-munging is in a different category. That's endpoint addressing and SOAP doesn't standardize it because SOAP endpoints are just URLs also. IMO, there are three issues that need to be standardized before you can talk to another system: * who can I talk to? * what can I ask them to do? * what data formats can I give them to work with? HTTP standardizes the first: "anything with an HTTP URI". HTTP standardizes the second: "PUT, POST, GET, DELETE". HTTP leaves the third entirely up to the application, as SOAP does (ignoring the SOAP encoding). It is the standardization of those first two things that makes HTTP an application protocol, in my mind. When you put an RPC protocol on top of it you lose the second standardization point and if you start passing parameters to GET-like methods in the XML body then you lose the standardization of the first also. After all, if the method is GET-like then clearly it is "addressing" so the standardized way is to put the addressing information in the URI. Paul Prescod 
|
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
|
|||||||||
