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?
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
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