An application programming interface (API) is a set of rules and procedures that allow two or more pieces of software to interact. The API of a given program will outwardly expose functionality and data, allowing developers to build complementary programs without having to access to its internal operations.

APIs have long been used within software environments – for example, an operating system exposes functionality to applications via APIs. But for the most part, it was not a piece of jargon anyone outside the IT department needed to know about. 

That has changed with the Internet. On the web, APIs are not simply technical interfaces between systems, but an opportunity for organisations to share information with the outside world.

It as an opportunity that many organisations are grasping. In 2005, there were just 105 web APIs listed on API tracker ProgrammableWeb. By December 2012, that number had risen to over 8,000.

APIs in public

One of the first major brands to support a web-facing API was online auction giant eBay. According to Delyn Simons, who was a senior manager at the company before joining US API consultancy Mashery, it did so in response to developers building ‘scraping’ tools that gleaned information on the latest auctions from its web pages.

“So many people were scraping eBay’s transactional data and trying to come up with seller tools that it felt their hand was almost forced to offer an API,” Simons says. For companies like eBay with particularly valuable or useful data, Simons says, a public API offers more control over how that data is used, as they can limit the amount of data this is pulled out through the API by any particular user.

“It’s much better to have an API that you can control and see how the usage is happening than allowing visitors to scrape your data, which drives IT teams crazy and is an additional load on the server,” she says. “Even if it’s more limited than what users want, developers will use it.”  

Furthermore, once that data has been exposed through an API, it can be used by third-party developers in new and innovative ways.

Forrester Research analyst Jeffrey Hammond points to Nike’s Fuelband API as a case in point. Fuelband is a wristband with a built-in gyroscope that detects a runner’s movements and links up to their iPhone. Nike decided to publish the API for Fuelband to allow third party developers to build iPhone apps.

“Nike actually told developers to go out and create music or jogging apps to synchronise music with the Fuelband,” he says. “There’s even one that makes you pick up your pace by simulating zombie attacks.”

By inviting third-party developers to use its data or services using an API, Hammond says companies can become capable of creating market-defining products and encourage the growth of its app ecosystem by attracting third-party developers. “Having that API opened Nike to innovation that they might not have thought of or wouldn’t have the developers to do themselves.”

The strategy has obvious attractions for companies whose business is the provision of information.

In November, financial media corporation Bloomberg launched an enterprise app portal to provide its subscribers access to speciality applications powered by its Bloomberg Professional service.

Instead of having its in-house coders build the portal’s applications, Bloomberg created a public API to foster growth of an app ecosystem populated with ones by third-party developers.

There are currently 45 applications available on the portal across categories including data analysis, news and research, portfolio management and risk analysis and data visualisation.

“Bloomberg provides a tremendous amount of functionality itself to its community so that we don’t have a monopoly on innovation,” says Stanley Young, CEO of enterprise products and solutions at Bloomberg. “It is important that we allow third party innovators through the app portal to bring that innovation and integrate it with our own Terminal products and solutions.”

Another example is the Press Association, which built an API for the London Olympics 2012 to expose data such as medal tables, schedules and results both to external partners, such as broadcasters, and internal development teams.

“The Olympics API was PA’s most comprehensive so far,” says John O’Donovan, director of technical architecture and development at the Press Association. “We ran data services for some of the biggest websites in the world – MSN, ESPN, Sky, Daily Mail, amongst others.”

The PA’s motivation in making data available to its partners through an API is to remove the complexity from handling its information. “Our job with APIs is to make something complicated, like the Olympics data feed, look simple to our clients,” he says. “This helps our partners worry less about the details and get on with developing the products they want to build that will add the maximum unique value to them.”

“Generally it’s easier to understand and work with an API that PA has constructed, than having to receive content and data in snippets and piece it together yourself,” he says. “Data is delivered faster, with more flexibility and can be plugged right into the required website or mobile service, rather than it having to be received, processed, stored and rendered.”

Nevetheless, he says, the API was sufficiently sophisticated to offer deep functionality to those that needed it, but simple, quick access to those with lighter requirements. “We were able to offer the flexibility of a full API, for those that wanted it, and the simplicity of widgets and other products built on top of the API to others,” he says. Not only can APIs unlock external innovation, they can also give organisations greater control over the way in which data is used by third-party developers.

This is done through API keys, says Forrester’s Hammond, a software mechanism assigned to individual developers that tracks and monitors their API usage.

“If you’re hiring a bunch of third-party development shops or agencies to do work with you, you’re going to need to define what access, information and rights they have,” he says. “A good way to do that is to issue a key linked to a certain class of access. “That way, the company knows exactly what they can access and can revoke those keys if there are issues with how they use the data.”

For cloud providers, APIs are a way to offer their functionality both to customers and to partners – a new twist on the old OEM principle.

Nimble is a US-based ‘social CRM’ provider, whose technology allows customers to manage their social media contacts through a cloud-hosted application. The company tracks conversations between a company and a customer over social media channels, and records them in a contact history for each customer.

The company wanted to expose its functionality to third parties, so it could be integrated into other marketing and lead generation systems. “The more Nimble can be integrated with other tools, the more value our customers can get out of it.”

Nimble has been working with consultancy Apigee to assess the requirements of its API, and how best to roll them out. “We sought to understand how the API would be used by our technology partners, both from a technical perspective as well as the types of things they want to do with Nimble,” he says.

“Apigee helped us enforce limits on API access to ensure no-one overwhelms our systems,” he says. “And they provide a developer portal, through which our customers and development partners can sign up for API access and learn more about the API.

Internals APIs

Most organisations deploying web APIs do so internally, says Mashery’s Simons. Private APIs can be used to integrate modular infrastructure services, which in turn can accelerate software development, she argues.

For example, exposing back-end functionality through an API allows developers to rapidly deploy new user interfaces without fiddling around with integration, she says. This is especially useful amid the current proliferation of end-user devices.

“It might take you six months to build an iPhone application, then another half a year on Android because none of the underlying code is reusable,” she says. “With an API, you’re not having to start from scratch with every individual device, which speeds things up.

Streaming video service Netflix has used this approach in developing support for “something like 800 devices”, Simons says.

Private internal APIs could prove useful in the event of a merger or acquisitions, if the two companies use different technology stacks. Most enterprises build their software in either a .NET or JAVA environment, Simons says, while web or mobile start-ups tend to use more esoteric, open source platforms.

“It can take time to get their technology built in and integrated into the core product infrastructure, so there is a lag time after the acquisition,” she says. “It will eventually happen, but instead of waiting for the new acquisition to take effect, they could talk to each other just about instantly via an API.”

So, there are ample use cases for an API. Of course, putting the strategy into practice is not so easy.

“The process around setting up an API is not as simple as many would think,” warns the Press Association’s O’Donovan. “Most importantly you have to consider what data you want to release, how it can be used and how you want to expose it through carefully designed methods.

“The scenarios around what data is available and how you think clients will want to use it have to be thought out from the outside, otherwise you may create an API which is unusable or complicated to support.”

According to Forrester’s Hammond, companies should start slowly when creating an API to make it as simple and accessible as possible for developers.

“You want to gradually expose capability and see how people use it and then go forward,” he says. “Documentation is critically important. You need to write documentations from a developers’ viewpoint.”

Developers will give up if they cannot easily figure out how an API works, Hammond adds. “Having a sandbox is also critically important. Developers need a place to test their code to see what it does and learn how things work.”

Hammond maintains that doing so is worth it in the end, particularly as creating an API may be necessary for companies to remain competitive in the future.

“It’s absolutely possible that businesses could get left behind if they don’t get involved with an API,” he says. “It would be like not having an enterprise architecture integration strategy 10 years ago.”