The rise of the API

You may not be aware of it, but you’re likely highly dependent on APIs, or ”application programming interfaces.” If you monitor your Twitter or Facebook accounts through a desktop or mobile device, if you scan a map to a venue that’s driven by Google Maps, if you check your flight status on your PDA, you’re benefiting from one company’s access to another company’s data set or software systems, defined and connected through an API.

Why should you care that you’re increasingly dependent on this little bits of techno protocol? Because, in part, your audiences, artists, and supporters are increasingly dependent, as well. Also, because the evolution of the Internet is closely aligned with the evolution of business. According to tech-watcher Robert Scoble:

Web 1994 was the ”get me a domain and a page” era.
Web 2000 was the ”make my page(s) interactive and put people on it” era.
Web 2010 is the ”get rid of pages and glue APIs and people together” era.

While the web experience used to be about individual pages and databases, accessible through Google search, the emerging experience is much more interconnected. What appear to be separate web pages and software programs are actually aggregations of multiple systems from multiple providers. And the next wave of web and mobile support will increasingly tie these tendrils together.

In fact, while we’re fond of saying ”there’s an app for that,” the reality is more often that there’s an ”interface to an API for that.” Much less catchy, I’ll admit, but an important distinction.

Again, why is this essential knowledge for arts and cultural managers? Because time- and place-based information is increasingly delivered through APIs, and consumers will increasingly expect to find what they’re looking for through these connections rather than through Google and individual web pages.

Want to go to a movie? You don’t need to go to movietickets.com if your system can access their API. Want to reserve a table at a nearby restaurant for after the movie? You don’t need to go to a restaurant website, or even OpenTable, if your personal digital assistant can be quietly searching, selecting, and reserving while you’re watching the film. Want, instead, to catch a live performance? Forget Google or the local arts web portal. Your system can grab data and book tickets through the APIs of Eventful or Livekick or a dozen other event systems. Better yet, since these systems can also link into the API of your Pandora radio stream or last.fm accounts, it can alert you to local events you’ll probably enjoy (and can share your interest with your friends through the APIs for Twitter or Facebook or LinkedIn).

You get the picture.

You’ll still need a web home in this evolving era. And you’ll still need a calendar somewhere on that web home (at least an embedded one through an API). But expect an increasing amount of business with your audiences, artists, and colleagues to be defined and delivered through someone else’s API.

Also, the rise of the API is more evidence that hoarding, controlling, or constraining essential access to your organization is a strategic blunder. If your calendar only lives on your system, on your web site, and for your direct visitors, it will turn into a ghost town. If your ticketing is limited to your box office, your phone staff, or even a single provider, you’ll be making it harder for audiences to buy.

NOTE: As a bit of irony, the Twitter API was broken when I posted this entry…proving that a more interconnected universe also makes us more vulnerable to other systems’ problems.

Related
Email this to someoneShare on FacebookTweet about this on TwitterShare on Reddit

Comments

  1. says

    It’s a shame there are no comments here yet. I can’t think of a better topic than this to define some of the core principles behind what will become the more successful technological platforms in the near future. You wrote “hoarding, controlling, or constraining essential access to your organization is a strategic blunder” and I think that’s putting it mildly but at the same time, some organizations will have to get over decades of entrenched proprietary ideology that is all but second nature.
    I hate to think that some groups will have to be shocked into this realization by crisis. Hopefully, that number will remain small.
    I had a conversation with a west-coast colleague who specializes in tech solutions for arts groups and one of his gripes was the lack of ability for arts groups to aggregate calendar information with a simple RSS feed. It seems as though this should be something easily implemented but unfortunately, much of the existing box office and event calendar components aren’t designed to generate RSS feeds automatically thus requiring a third party to manually collect event info and punch it into an aggregate calendar. All in all, it’s an embarrassingly backward limitation throughout the arts field.

  2. says

    Great article and it makes an important point.
    Full disclosure, I am a developer for InstantEncore, so I have some skin in the game when it comes to this. We have built a very powerful content management system which powers our classical music community.
    However, we know that there are a lot of creative people out there who can do an unlimited number of things with this data. To that end we’ve built an API (concert listings only right now – though it’s expanding to include music, videos, etc). You can see more at instantencore.com/api. Also we have RSS feeds for music, concerts, videos and buzz for every artist, composer, ensemble, conductor and presenter on instantencore. To access those just go to InstantEncore.com and search for an artist. On their page you should see the familiar RSS icon in your browser url bar.
    We believe that the API systems can save a lot of time and money and offer a world of new opportunities.
    Thanks again for bringing light to this important subject.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>