API is the new Site Map

Monday, January 1, 2007

I made an off the cuff remark to Adrian a while back and I don't even remember why I said it

API is the new sitemap

But it keeps coming back to me bouncing around inside my head. Here are the loose collection of rambling thoughts I've had so far.

Thomas Vander Wal talks about the " Come To Me Web" as opposed to what came before, the "I Go Get Web" and it occurs to me that the site map is a remnant of the the "I Go Get Web". It's a device by which a visitor can attempt to find something on your site and it has always been among the attributes of a well designed website.

But these days you don't want to have to go and find things you want things to come to you. That's where the API comes in, you just make the request and the information is delivered. Even better, the information is delivered simply because some software agent is aware you are interested in such a piece of information.

It reminds me of a situation I find myself in using an RSS Reader: there are many sites I read now that I never visit. but there's often a piece of info I want to recall after reading it in my RSS reader. The reader assists me with this by allowing me to mark entries and so forth. The important thing is that the website I'm reading has nothing to do with assisting me. Sure I could go visit the website and look for a search form and see if I can find it that way, but why would I bother? My RSS Reader does it much better.

RSS is a syndication of all your content, an API of sorts. It is an answer to my question: 'what's there that I haven't read?'.

The same syndication could be done for all kinds of details and information. I think all websites would benefit from having an API.

What if every website had a 'contact information' API that returned a hCard microformat. Now it's could be the raw hCard data or a standard webpage containing the hCard data, it doesn't matter. It could use a link XHTML element like this:

<link rel="contact" type="text/hcard" href="/contact" />

to indicate where the information is. That way our address books can subscribe to all our contacts' information via an automated/updatable mechanism just like RSS and bloody well keep themselves up to date!

I like the idea of XFN , but I'm hesitant to keep adding my XFN information to a lot of different social network websites. Why can't I have a

<link rel="xfn" href="/xfn" />

on my homepage And let software agents take care of it for me? It means there's only one set of data for me to maintain. Then all the social networking tools/sites I use and participate in can discover and subscribe to my XFN feed.

Of course all of this information can be coded as microformats into your webpages, and automated software agents can crawl and discover them, but I think that is not the same as an API. An API is not discovery it is direct inquiry. I make a request and I expect an accurate answer. One of the reasons RSS has been so succesful is that it is effortless. No extra work for the author and no work for the reader. It's effortless to find an RSS feed and subscribe to it. All website information should be so too.

All of the problems site maps were designed to solve could be replaced with APIs. If every commerce website published a compatible product information feed then I could use whatever software tool I liked to browse catelogs or find specific items. If personal website owners published their own recommendation feeds, then my software could merge the two data sets and help me make my decisions.

Thus my personal website becomes my identity, a concept promoted by OpenID , from which I syndicate all the information I wish to share and automated software agents can do the rest. After all it's better that they do all the work, that's what they are there for.

FOLLOW-UP: API is the new Site Map Part 2

Random outings from a chaotic mind