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.