Comments on: APIs Suck http://inkdroid.org/journal/2009/03/05/apis-suck/ $pithy_personal_mission_statement Wed, 10 Mar 2010 02:04:23 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: ed http://inkdroid.org/journal/2009/03/05/apis-suck/comment-page-1/#comment-81220 ed Sat, 07 Mar 2009 18:34:20 +0000 http://inkdroid.org/journal/?p=831#comment-81220 Yeah, agreed on it not being either/or. But my main point is that it's probably easiest to make the data available first in some raw form, and then make the shiny API later--after it's easier to see how people are using the data. I guess the title of my blog post sucks, much more than APIs :-) Yeah, agreed on it not being either/or. But my main point is that it’s probably easiest to make the data available first in some raw form, and then make the shiny API later–after it’s easier to see how people are using the data.

I guess the title of my blog post sucks, much more than APIs :-)

]]> By: dilettantes.blogspot.com/ http://inkdroid.org/journal/2009/03/05/apis-suck/comment-page-1/#comment-81219 dilettantes.blogspot.com/ Sat, 07 Mar 2009 17:24:53 +0000 http://inkdroid.org/journal/?p=831#comment-81219 I know Anders was being kind of flip when he made this remark (since immediately after it he said that Libris had APIs and that's what they used), but I also think sentiment is a little disingenuous. APIs that suck suck. On the flipside, if all we had to work with from any organization where big dumps of data, <em>that would probably suck even more</em>. The notion of having to bootstrap a heap of data into some usable form, just to even see if there's anything useful in it, seems inefficient and counter productive. I guess my point is, this isn't an either/or proposition. There are plenty of organizations that provide both an API <em>and</em> their entire data set. Govtrack.us does this nicely, I think. You can pick and choose between entire datasets and a la carte access as your needs determine. I readily admit that I'm biased on this. For the last year, majority of my time has been spent designing an API intended primarily to make all of your data available for reuse. Still, it's an API. There will be data (personal, borrower data, for example) that people will want to control. At least, I hope people will want to control. But just because it's an API, doesn't mean that it's the same thing as Facebook's or Worldcat's API. An API doesn't <em>inherently</em> have to be restrictive. There are just some organizations that feel less restriction on the use of their data is more disruptive than they feel comfortable with, with regard to their business model. That's a totally different blog post comment, however. I know Anders was being kind of flip when he made this remark (since immediately after it he said that Libris had APIs and that’s what they used), but I also think sentiment is a little disingenuous. APIs that suck suck. On the flipside, if all we had to work with from any organization where big dumps of data, that would probably suck even more. The notion of having to bootstrap a heap of data into some usable form, just to even see if there’s anything useful in it, seems inefficient and counter productive.

I guess my point is, this isn’t an either/or proposition. There are plenty of organizations that provide both an API and their entire data set. Govtrack.us does this nicely, I think. You can pick and choose between entire datasets and a la carte access as your needs determine.

I readily admit that I’m biased on this. For the last year, majority of my time has been spent designing an API intended primarily to make all of your data available for reuse. Still, it’s an API. There will be data (personal, borrower data, for example) that people will want to control. At least, I hope people will want to control.

But just because it’s an API, doesn’t mean that it’s the same thing as Facebook’s or Worldcat’s API. An API doesn’t inherently have to be restrictive. There are just some organizations that feel less restriction on the use of their data is more disruptive than they feel comfortable with, with regard to their business model.

That’s a totally different blog post comment, however.

]]>