« Simulated Ants! | Main | Portfolio (n) ... »

July 09, 2007

Six basic truths of free APIs

Nat Torkington in Six Basic Truths of Free APIs (with commentary here, here and here) reminds us that there is no such thing as a free lunch in the area of Web 2.0 APIs - or not very often anyway. My own advice (which is pretty mundane it has to be said) is to code to the lowest common denominator API - RSS - whenever possible.  That way you can pretty much throw away the service giving you the feed and replace it with something else, should the need arise, without a significant requirement to re-develop your code.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Six basic truths of free APIs:


I'm not sure RSS is really an API. It's a format (or a family of formats).

I think the "lowest common denominator API" is probably the "uniform interface" specified by the HTTP protocol, and the ability of a client to "follow its nose" in determining the "meaning" of the responses. See e.g.


I guess there's a level above that where there is also consensus on the use of some specified format or set of formats, so maybe that is closer to the notion here of an "API".

Sigh... blog in haste, repent at leisure.

Pete is right. RSS is not an API as such... though I stand by what I meant to say, i.e. that coding to the combination of RSS and HTTP whenever possible is a good thing [tm].

I remember asking you in the past: which RSS? But now: is Atom better specified for the kinds of jobs you are talking about? In a later post you talk about SWORD, built using Atom...

Good question... and one that a) I found I was asking myself, and b) I found that I didn't really know the answer to!

Note that Pete wrote the entry about SWORD, not me - though in general we tend to speak with one voice! :-)

When I read Pete's entry about SWORD my initial reaction was "so that makes Atom the obvious choice of API and format for getting stuff in and out of repositories".

My only slight reservation about saying that, particularly w.r.t. getting stuff out of repositories, has to do with rate of uptake of Atom vs. RSS (ignoring the multiple-flavor issue).

From a programming perspective, the "which RSS?" question is somewhat moot - in my experience the various programming language libraries hide the differences pretty well (at least for trivial use).

Atom, I guess, is different - though I've never programmed Atom so I don't know for sure.

From a client viewpoint (i.e. in terms of the kinds of tools you and I might use on our desktops or on the Web), most tools seem to support both RSS and Atom anyway, so I don't think much would be lost if repositories chose to support only Atom, rather than both Atom and RSS.

To sum up, yes, I think that Atom probably deserves significant consideration as the API and format of choice for getting stuff in and out of repositories, but note that there will be times that sitemaps will also meet a functional need not catered for by Atom.

... and I just read today the July 2 posting in O-Reilly's XML Blog: http://www.oreillynet.com/xml/blog/2007/07/app_is_coming_to_apache.html. "This is a pivotal achievement, and one that will rocket APP into daily use. APP ... uses extend considerably beyond the normal scope for blogging and could very well be a staple of most data publishing systems within the next few years."

Ah cool. Thanks. I hadn't spotted that.

Of course, there were similar Apache module announcements for both the OAI-PMH and WebDav, neither of which resulted in significant uptake (significant in terms of the number of Web servers out there I mean) - so we'll have to wait and see.

But I agree, this is a positive and potentially important development.

The comments to this entry are closed.



eFoundations is powered by TypePad