Working with APIs (part 4, the end)

Since the third installment of the introductory “Working with APIs” series (also: parts 1, 2), I’ve been thinking about how to wrap up the series. I wanted to show examples of coding interfaces to APIs—in fact I even said that in this installment “I’ll show you some nifty tricks that involve server-side programming,” but there’s a lot to cover between pulling data from query strings or modifying attributes of widgets and using server-side scripting to do custom work.

Instead, I’m going to wrap up this series by talking about why I keep harping on the use of APIs and knowing how things work: the web is a platform. This is not a new idea. It is, in fact, the first point of Tim O’Reilly’s “What Is Web 2.0″ article from 2005:

Like many important concepts, Web 2.0 doesn’t have a hard boundary, but rather, a gravitational core. You can visualize Web 2.0 as a set of principles and practices that tie together a veritable solar system of sites that demonstrate some or all of those principles, at a varying distance from that core.

O’Reilly’s other key points (“Harnessing Collective Intelligence,” “Data is the Next Intel Inside,” “End of the Software Release Cycle, “Software Above the Level of a Single Device”, “Rich User Experiences”) also work well to support an argument regarding the importance of knowing how and when to leverage APIs, but I want to focus on this additional discussion point in the O’Reilly’s article: Lightweight Programming Models. In this section he talks about the different types of web services—SOAP (Simple Object Access Protocol) and REST (Representational State Transfer)—and the ways in which the ability to use these services to access existing data warehouses leads to creative ways of remixing data for additional uses. Specifically, O’Reilly notes “the most successful web services are those that have been easiest to take in new directions unimagined by their creators.”

Although O’Reilly’s “What is Web 2.0″ focused entirely on industry uses and benefits, in the last several years we’ve seen a significant rise in the creation of and use of APIs in academic work as well. I can only speak as someone invested in the Digital Humanities, but I would venture to guess that new ways of accessing and sharing data are prevalent in other fields as well.

A few days ago, researchers and programmers from some of the key online projects in Canada, the US and the UK gathered in Mississauga, Ontario for a Workshop on Application Programming Interfaces for the Digital Humanities. One of the goals of this workshop was to “develop a strategy for providing APIs that mesh seamlessly with one another, expose data that has remained inaccessible until now, and provide a platform for a new generation of online research.”

APIs provide a layer of accessibility to data, it’s true. But people still collect and organize that data; archivists who work with physical artifacts are as important to the “new generation of online research” as those of us who want to digitize that content and create tools to share it outside the boundaries of the physical archive—into that online space without hard boundaries.

The reason I want everyone to have a conceptual understanding of APIs, or using XML as a data interchange format, is so that this decentralized approach or “new generation of online research” does include as many voices as possible—you might not be doing any of the programming, but at least you will know the possibilities and some of the vocabulary necessary to communicate with those who are.

[Graphic taken from a screenshot of the current most popular APIs for mashups according to ProgrammableWeb. Look for additional and more technical discussions on APIs from yours truly at ProgrammableWeb in the future.]