Return to open APIs

In 2014, web app APIs basically look like this:

  • JSON or XML API layer for a web site's content and functionality.
  • Potential client developers must register with the web site and get some kind of API key for access.
  • OAuth is used to grant access without giving out passwords.

A more cynical view of that last point could be rewritten as: OAuth is used to control and limit access so that the API is inaccessible without approval from the web site.

This all seems fairly normal today. I required an API key for Tweet Marker because that’s just what you did, especially if you wanted to charge or limit an API. But it didn’t always used to be this way — remember when you could hit the Twitter API with just a user’s password? — and it doesn’t have to be this way forever.

For my next web app I’m going to have an API that is more open, requiring no app registration. Instead it will be user-centric, with password tokens that a user can paste into their favorite compatible app for authentication. (My web app doesn’t have traditional passwords at all.)

Not having API keys removes a whole set of complexity: no need to write all the backend code to support managing them, no need for developers to register, no need for me to judge who should get access. Whenever possible, APIs should be nearly as open as the normal web, where Safari and “curl” don’t need to register with a web site just to download its home page. Users are in the best position to know which apps should get access to their account anyway.

If we can loosen APIs, I think it makes the web better. Dave Winer takes it one step further:

"What we really need, and I hope to help make happen, is a network based on open syndication of content. Then there is no one to ask for an API, because there's no one in charge."

I’ve been calling my latest project halfway decentralized. I’m still in charge, but just barely.

Manton Reece @manton