the iCite net > news / blog > a permalink

news and thoughts on and around the development of the iCite net
by Jay Fienberg

More RPC addressibility ideas

posted: May 15, 2003 4:09:26 PM

Following on my last post about needing a way to address information that is available through SOAP or XML-RPC interfaces, and that perhaps don't otherwise have a direct one-line HTTP GET URI, I just looked more closely at Really Simple Discovery (RSD), which is a bit of XML that describes an RPC interface.

I was thinking that the main elements of an RPC "address" are any actual URI address parts, plus the protocol/format (e.g., SOAP or XML-RPC), plus the API. But, when there is a known API, like the Blogger API or the Manila-RPC API, the API implies a particular protocol / format like XML-RPC, right?

Actually, wrong! Manila-RPC supports both SOAP and XML-RPC. The blog APIs like Blogger are only XML-RPC, but since something that references the Manila-RPC API might need to indicate either SOAP or XML-RPC, it is safe to bet that there will be other cases where handling multiple protocols needs to be taken into account.

So, first, what I was thinking was that an "address" to information accessible by RPC could look like:

   * a URI to a RSD document describing the RPC interfaces
   * the "post" ID of the information

What this would mean is that whatever applications were using the RPC "address" would need to be able to take the RSD document and parse out the API info, and then know how to grab information using that API. As a way to picture this, imagine a RPC browser application that takes RPC "addresses" and returns information. That application needs to know how to use the RPC APIs, the way a web browser needs to know how to handle HTTP GET and FTP RETR, etc.

RSD can list multiple APIs and indicate which is preferred. And, RSD can list the "blogID", which is one part of the total identifier of the information (e.g., blogID + postID). But, RSD does not have an attribute for protocol (e.g., SOAP vs XML-RPC). And, in general, all of this is around blog APIs where there aren't a lot of choices for the "getPost" methods in each API.

So, I don't think RSD, as it is, is quite cut-out for a general case of an "address" for RPC information. And, it wasn't designed with this in mind, so please don't take this as a criticism of RSD. But, it suggests to me a prototype for a way to summarize the parameters around an RPC access point.

The most simple pieces I think are needed in an RPC "address" are:

   * a URI to the RPC access point
   * the name of the RPC protocol
   * a URI to the payload (input) of the RPC call, including the method name and paramter values

I think this would cover the case for both RPC over HTTP and also over other lower level protocols. I think, if it were only over HTTP, the name of the RPC protocol wouldn't be necessary. I need to look into this more.

A variant on this would be, instead of using the payload, to list the method and all the parameters. This is easy to imagine when talking about getPost with a blogID, a postID, a username and password. But, what if a more complex data structure is required as a paramter value?

So, I was thinking that someone should create a service--maybe I should do it as part of the iCite net, that is like TinyURL but is instead TinyRPC. Basically, it would take as inputs the three things above and return a tiny URL that is a shortcut for the whole RPC call.

Perhaps what is ironic about all of this is that, I think, the reason why there is appreciation of these RPC protocols / interfaces is that they can be treated purely programmatically--e.g., if I use the Apache XML-RPC client, I don't have to think about or touch XML. This "you don't have to touch the XML" point is discussed by Sam Ruby and Dave Winer in their comments on Sam's HTML GET Rocks post.

I guess I am proposing a RESTful overlay on top of this, that just happens to not have every parameter / value directly crammed in a single GET URI (though the GET URI would at least refer to all the parameter / values). I think that is a little different than the approach of making RPC RESTful by cramming all of the parameter / values into a single URI.

permalink | comments {0} · trackbacks {0}

also available as: rss · rss2 · rdf · atom

Comments and Tracbacks

Note: All comments and trackbacks are moderated. Spam is deleted. Other comments are approved as promptly as possible.

Note: Older posts no longer accept new comments or trackbacks.

« prev post
REST and RPC, addressibility questions

» next post
My big fat geek blogroll

blog newsfeeds

brief content:

 XML  ·  RSS  ·  RDF  ·  Atom 


full content:

 XML  ·  RSS  ·  RDF  ·  Atom 


blog archive

2006:
jan · feb · mar · apr
may · jun · jul · aug 
sep · oct · nov · dec
		
2005:
jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

2004:
jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

2003:
may · jun · jul · aug
sep · oct · nov · dec

first post: 
April 30, 2003

highlight views:
Spammers' Choice
		

Jay elsewhere online
Jay Fienberg - the official home page

Wrong Notes - the music blog of the Ear Reverends

Fine & Full, aka, a fine and full burger

Sociomobilepoetextologia (moblog, currently inactive due to lack of proper mobile)

to enjoy roll
sites I like to read when I start from here

· Anastasia Fuller
· Andy Baio
· Biz Stone
· Boris Mann
· Bre Pettis
· Chris Dent
· Danny Ayers
· Dare Obasanjo
· David Czarnecki
· David Weinberger
· Don Park
· Evan Williams
· Greg Narain
· Jason Kottke
· Jim Benson
· Lucas Gonze
· Marc Canter
· Matt May
· Matt Mullenweg
· Michal Migurski
· Nancy White
· Rebecca Blood
· Reg Cheramy
· Richard MacManus
· Sam Ruby
· Shelley Powers
· Tim Bray
· danah boyd


powered by blojsom


Entries by blojsim