How to… start using APIs
How to… start using APIs
By
James McVeigh
Edinburgh Festivals' Head of Marketing and Innovation James McVeigh takes us through the background of how they started using Application Programming Interfaces (APIs) to provide media listings.
Challenge: How do we enhance the service by which we provide the media with our programme listings?
Solution: Develop a Listings API [Application Programming Interface]
Project Outline
An Application Programming Interface or API is a technology by which one data source makes itself available to being used as the input for services by outside parties building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer then puts the blocks together.
Putting all the techno-babble to one side there was one main reason why the Listings API project was important to us. Cultural organisations typically publicly provide their listings either through a printed programme or their own website. In the course of any given year our Festivals would manually provide customised listings files to a select group of press/media partners - a task that was labour-intensive and provided static information despite the dynamic nature of listings changed.
By creating an API we felt that we could provide an automated system by which any press or media outlet in the world could have access to individual or collective festival listings - thereby raising the reach of event information.
In 2011 we began the process of creating a central database of the festivals listings by taking live feeds from either the box office or website of each individual festival. This central database was the source for the API. Users could access the API through a secure registration system [see above] with the data updated regularly to ensure quality and the data provided under specific license terms to ensure users would keep their applications up to date. Press/media users such as newspapers and magazines were able to take the listings in a variety of formats designed for widest possibel ease of integration and reproduce them in their own online and offline channels.
Results
In its first year it included seven summer festivals and served ten press/media users. and in 2012 included all twelve festivals as represented by Festivals Edinburgh. By 2013, the API usage had significantly increased to a point where it served a total of 1.02 million requests from 39 external users [as illustarted above] – a significant increase on the 126,000 requests (from 32 external users) handled in 2012.
In 2014 we appointed Edinburgh-based company Ingenerator to develop both the supply and demand ends of the API. At the supply side we are finalising the creation of an input mechanism which will allow the Festivals to have direct control of what they wish to upload into the API – which has the benefit of allowing for the enhancement of existing feeds, possibly through incorporation of additional text or imagery. This interface will be an importance feature in the development of the API as a repository for festival history, in essence a digital archive. We can already see this in action through the retention of 2012 and 2013 listings in public format, the first time that such Festivals ‘archives’ have been made available. In addition to this supply side, we have developed new functionality to our public registration site which provides a specific support structure to encourage take-up by partners thus enhancing the reach of the API.
The scale of Edinburgh Festivals and their audiences mean that there is a lot of interest in this kind of activity and the API enables the potential creation of new services that are useful for audiences, performers and local businesses. This was the basis of our creation of the country's first ever Culture Hack day .......but that's another story, another case study.
James McVeigh