Today’s Debate Question: What’s an Open API?

In N-TEN’s “Great Open API Debate” on Friday, the panelists were all in agreement: Open API’s are great, they’re the wave of the future, everyone should be using them, offering them, building them. Now there’s just one small point of clarification: what’s an Open API?

This debate is in serious need of some definitional clarity. How open does open need to be? What’s the difference between an API and an Open API? What’s the difference between offering access to data and an API? Without a definition as to what is or is not an Open API, it’s hard to do a reality check when all the vendors say they're already offering one, or will have one soon.

Allan Benamer (of the Confessions of a Nonprofit IT Director blog) has helped me out with some thoughts on what it should take to be an Open API from a data perspective. Let’s call them the Four Pillars of Open APIs. Each aspect is useful on its own, but with all four you get the Open API gold star.
  1. Uses open standards. The application can give me data that other applications can read, and I can access it using a language that other people use
  2. Supported and documented. I can figure out how to use the API
  3. Access to all user inputted data. I can get out via API all the data my organization and my supporters put in.
  4. Free (or at least fairly priced). I don’t have to sell my unborn child to access the API

What do you think? And stay tuned for more from Allan.

Comments

Good points. I'm very active

Good points. I'm very active in API design, testing, and promotions, and can tell you that the API has to be code tested by outside subjects.

Non-intervention User Observation tests are mandatory. Alienate the developer community with an API for a buggy product, or a defective API code, and you're dead.

Many API providers seek to attract top developers, hoping they will build mashups and sophisticated applications, that will result in the next YouTube, Digg, flickr, Weblogsinc., Google Maps, eBay, Amazon, what have you.

But the developer site must have the right tools suite and generous support systems.

XML and SOAP. Developers forum, wiki, and blogs. Contests. Clickable promo buttons. "Sites using our API" list. Encouraged and enabled interactions between developers, so they can ask each other questions and collaborate.

I'd add that the APIs need to

I'd add that the APIs need to be Internet-based. The most power and flexibility come when you can connect systems that don't need to be on the same servers.