After the introduction to APIs and API critiques Bernard Rieder talked about APIs from the perspective of  “Variation and Change.” This transcript is compiled from collaborative notes by the Digital Methods Initiative.

API: a means and protocol for two systems to exchange data and functionality.

APIs can be seen as data sources and as objects of study that can be historicized, analyzed, critiqued, etc. Before taking the API as a research object we also need to get a better understanding of “what we can get” out of APIs and asses our level of confidence when researching. The API can be used as a means to study a service and possibly the evolution of the Web?

The ‘past’

Andrew D. Birrel and Bruce Jay Nelson, Implementing Remote Procedure Calls, ACM Transactions on Computer Systems 2(1):39-59, February 1984.

Webservices, SOA –   XML-RPC, SOAP, WSDL – B2B, e-commerce

Google SOAP Web API: 2002 (Java, .NET), Amazon Web Services: 2002

The history of APIs; they came out of business context, B2B, e-commerce transactions, to ensure transactional integrity. They were heavy protocols first written in ‘hard-core’ programming languages such as Java and not PEARL, PHP and JavaScript.

The ‘turn’

Flickr (feb 2004), API (aug 2004): Easy to use API. Less about transactional integrity.

Google maps (feb 2005). The Housing Maps project (march 2005)  used two scrapers. Google Maps was reverse-engineered to extract the tiles (the individual images that make up the map). Next, he scraped the data from Craigslist and combined the two. After this, Google hired the guy and implemented the API a few months later (June 2005).

Programmable  Web has a API directory and lists the most used APIs which allows for historical comparison on APIs. For example, in 2007 there are no social networks and Google maps is 1st and Flickr is 2nd. Now, in 2012, Google maps is still 1st but Twitter is 2nd and Facebook is 6th.

The turn also entails a shift from a hard heavy business logic, to a soft logic.

Lines of variation and change

An investigation into synchronous/diachronous lines of variation and change can serve as API critique or historical analysis. Questions may concern:

  • technical structure and use (how?) – how similar is the tech infrastructure for developers to the platform’s view?
  • intended audience, intended use (who?) – audience: both developers and end-users
  • economic model (why?)
  • restriction and tolerance (legal, technical, transparency, etc). Restrictions: Explicit or not
  • developer relations (communication, support, etc). Questions: How do their organize there documents? How do they communicate it? What does it say over there relationship with users? How does it change over time?
  • publicness and authentication (privacy, ego-view) – Facebook has an open API, the search API. There are variations of authentication.
  • coverage and discrepancy (API, “user view”) – The API and frontend often do not have the same results
  • read/write capacities (location in the flow) – and possible use of this information to infer how the service views itself vis-a-vis other systems