Most of my thinking about how iCite links work has assumed that a link is defined by a URI. So, a link looks like http://icite.net/blog etc.

I am thinking about iCites and XML-RPC and SOAP, and have concluded that, since XML-RPC and SOAP calls are not formed as URIs, I shouldn't try to imagine that iCite links that at least look like URIs should be what is used to represent XML-RPC or SOAP calls. There is a proposal for SOAP called SOAP HTTP GET Binding that, if I understand it correctly, says "here is how to create URIs for SOAP calls that are simple enough to be expressed in a GET". This goes with SOAP implementations that support GET gateway interfaces.

In the discussion about ThreadsML, I brought up the case where a post in a thread is related back to its source via a URI. So, it is prety easy to imagine that a post came from or lives at http://icite.net/blog/200305/rest_rpc.html.

But, I have been wondering about the case where some information is only accessible through XML-RPC or SOAP. In this case, the information is, to me at least, as addressable as a URI accessible resource, but the address isn't just a one liner.

I want to mention, just in case anyone has a similar background, that I used to program in APL. And, in APL, whole programs can really be written on a single line. (See the section on "How Does APL Compare to Other Languages" on the APL page I link to.) I think, with the REST approach, in some sense, part of the attraction is that you can write a "whole program" in a single URI.

So, I saw Sam Ruby's post today on HTTP GET Rocks and his reference to his post with a simple SOAP example. I find this stuff interesting and clarifying, though I feel a little confused by the wrangling going on between the REST folks, the XML-RPC folks, and the SOAP folks--they all seem to have some beefs with each other's approaches--or maybe some beefs with the fact that the others have beefs about their approach and they shouldn't, or something.

Here at the iCite net, we just imagine lots of links, and lots of lists of links, and and lots of lists of lists. Purdy dumb, I know, but it is what we don't get paid for around here.

So, I think iCites need to support, besides URIs, URIs plus chunks of XML that represent RPC calls. And, then I have this other idea about iCites supporting RESTful proxy URIs that translate to under the covers RPC.

To use a simple, practical, but unrealistic, example, let's imagine there is a blog entry that is ONLY accessible via the Blogger API--you can't get to it via a web URL. So, the proxy would be a URI that, on the backend, uses the Blogger API to get the post, and returns it as if it just lives at the URI.

I think this is basically what SOAP HTTP GET Binding wants to do. But, in this "proxy", I imagine that the proxy can hold data not in the URI, but needed for the RPC call. So, for example, the Blogger API requires a username and password, even to get a post (blogger.getPost). The proxy could take simply the post ID in the URI, and the behind the scenes server side script / program could use a username / password from a properties file, for example.

I guess this isn't going anywhere right now--just some thoughts on how flexible to make iCite links and what those links mean. And, I also want to help make suggestions about this for ThreadsML. Let me know if you have any ideas about this.