API, an abbreviation of application program interface, is a set of routines, protocols, and tools for 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.
How do you make your content available to all those new mobile devices? How about linking your Content Management System with software X? What about linking your content more closely with your metadata? Perhaps the overall question is how do you make your content agile? There are numerous answers to all of these questions, but one way to get your data out there may be to make it available via an API.
Last fall at one of the CMPTO events Pearson did a presentation on some of their newly available content APIs and one or two of the projects being built using their APIs. At the time Pearson was very honest in saying that this was really a test bed. They didn’t really know where it was going to go, but that they had high hopes for where it might go. I thought this was great—get it done, make it available and see what happens.
One of the things that piqued my interest at the time was a discussion around micro-payments for content usage. How can you make your content available so that developers can use it in their products, but still generate some revenue? One way could be using a pay per usage model based around a system of monitored API usage and a method for accepting micro-payments.
It looks as if Pearson will be announcing just such a platform at Mobile World Congress 2012 this week:
…Pearson’s API data has been free to use by developers, and that will continue to be the case, but with the agreement in place now with Zuora, once the usage of that data reaches a certain threshold—what that is depends on the data in question—developers will have to pay a charge to use it. Developers keep all the IP around whatever apps and services they create using the data.
I’m sure there are other publishers out there that have their own content APIs, or are working on that, and we would love to hear about it.
PS. We have our own BiblioShare APIs for sharing bibliographic data.
