APIs and their business relevance

API: acronym for Application Programming Interface. An API is the way to make software programs “easy to plug and share” with other programs.

An API is simply a group of rules (you can also call it a convention, or an agreement…​) which programmers follow when writing the part of their code which is in charge of communicating with other software. These rules are then published (on a webpage for example), so that anyone who needs to connect to the program can learn what rules to follow.

Is an API simply a way to write code to interface with other programs? Yes. Why the fuss then? Having conventions on how to write a software so that somebody can plug it to its own software is one thing. APIs as an aspect of software design is a classic topic in computer science, but we are not concerned with this here.

APIs we are going to discuss are about communication between distant computers, in a business context. To understand better their business relevance, it is useful to recall a brief history of APIs:

Companies which need to exchange data is nothing new. Manufacturers, retailers, banks, …​ they need to exchange information at regular interval.

Sending invoices, receiving receipts for merchandise, and many other administrative records generated in the course of business.

These receipts, invoices…​ can be printed and mailed (this solution still exists of course).

With informatics developing in the 1970s and 1980s, a new system emerged: the exchange of information via computers: Electronic Data Interchange.

EDI EDI - Eletronic Data Interchange is not an exchange of file attachments in emails or via a file transfer on a website, because emails and websites did not exist yet! (emails and the Web were adopted by firms in the late 1990s).

Instead, exchanging data via EDI consisted in using complex electronic tools (like the fax but even more complicated) because:

To summarize: EDIs are fragmented, complicated to implement, slow to evolve, expensive and restricts the communication to a "club" of partners who agreed to use it.

EDIs still exist, especially in large B2B industries like transportation, but it lost in popularity in the wider economy because…​ APIs have arrived.

In the late 1990s and early 2000s, Internet and the World Wide Web expanded dramatically. More and more servers in different parts of the world needed to exchange data with each other, and this required to use interfaces more convenient than EDIs.

It became increasingly convenient to define simple and universal conventions that everyone could learn and follow to standardize these exchanges, for free and easily. That is what web APIs do. They are also often called:

A web API extends the logic of the APIs we have seen in the beginning of this document, to software communicating via the web. To recall, an API is a convention followed when writing a software, making this software available to other software.

A Web API is an API which enables two pieces of software to communicate, via Internet. They do not need to be installed on the same computer.

Unlike an EDI, a web API drops any industry-specific concern. Web APIs are just a convention to send and receive data over the Internet, without any saying on the content of the data.

The data sent and received can be invoices, webpages, train schedules, audio, video…​ whatever. Contrary to an EDI, a company creating a web API can choose to leave its access open (remember that EDIs need the two parties to have a pre-established agreement).

So that a potential client interested in using the web API of a company can set it up in a couple of clicks, instead of waiting weeks or months before a contract is signed and the EDI is setup.

Two popular web API conventions emerged in the 1990s and competed for popularity:

REST APIs became ultimately the most widely adopted, because it uses the same simple principles that webpages use to be transferred over the Internet (the "http" protocol that you see in web page addresses). This is why APIs are often called "REST APIs, presented in this pedagogical video".

In 2000-2010, it became increasingly easy and natural to adopt the REST convention to make one’s software and data available to another computer. This simple evolution to ease interoperability had immense effects:

An API transforms a closed software into something that can be plugged to anything other computer or object, as long as it is connected to the Internet.

For instance, APIs were a key factor of success for SalesForce in the early 2000s. SalesForce, created in 1999, has a revenue of US$8.39 billion in 2017:

SalesForce takes a commission on the sales made by these third party apps hosted on Force.com, but more importantly, the platform creates an ecosystem of apps and developers around the SalesForce products which makes it hard for a customer company to switch to a different product.

Thanks to API it is now easier to add software blocks together and create new apps, even if these software blocks originate from different countries, industries, big and small.

As an extreme example: the Australian Victoria Police deployed a project for the recognition of stolen vehicles through the video recognition of licence plates on cars passing in the street (stolen vehicles get their license plates immediately recognized). This is a $86,000,000 project. An individual actually replicated this project with just 57 lines of code and a dashcam. How so? Just because he could use existing software for licence plate recognition, available as an API, instead of re-developing this by himself.

Another example: Peter Levels demonstrated the potential of APIs by building a "Luggage delivery service" just with existing apps connected together via their APIs. Without a line of code:

This service is designed by organizing several sub-services, which coordinate by communicating via their APIs.

How does communication work? Who "orchestrates" these services? Peter uses Zappier, a service whose role is to make these APIs communicate with each other. Beyond these striking examples, the lessons to be learned are:

Companies and public organization own many datasets of great business interest. The use of these datasets can be free (for small projects and NGOs) or monetized if the user is an enterprise.

Without APIs, datasets can be made publicly available as docs (eg, Excel spreadsheets) to download but this is not practical (try downloading something like all_train_schedules_2000_to_2017.xls !).

Let’s take the example of a transportation company like French SNCF which finds it interesting to publish station names, train schedules, real time information on train traffic, etc. because it could be used by other companies to build new services : how can it do it?

Open data designates this movement to make datasets available to a broad audience, and web APIs have been a key technological ingredient in this movement.

A company can create its own APIs to "project" its services farther and stronger than just the "web page" interface. When is it a good idea to do that?

Here we must brainstorm, with two benchmarks to keep in mind. These examples are taken from Pieter Levels, a Dutch entrepreneur who specializes in creating web platforms for remote workers. He created:

Pieter Levels has implemented APIs so that users can access ("consume") these two services, with very different results:

The screenshot below summarizes the contrast between the two situations: although in both cases it involves opening its data via an API. Between NomadList and RemoteOK, the results are opposite:

Product managers must have a fine appreciation of the uses that the opening of an API will stimulate. One of the most virtuous effects is that of a "sound box": by reusing our content for their own purposes, the users of the API will unwittingly promote our content, which reinforces the efficiency of our product.

To discover new APIs, or to make your APIs easier to discover, the most well known place is the website "Programmable Web" (see also apis.io). Searching on this website, you will find APIs providing business services, or APIs of a fun and odd sort.

Still, many APIs are not listed on this website, and a google search for "info I need + API" is also a good way to find if the API you need exists. Interested in whale sightings? There is an API for that.

APIs have become central to the economy. As a result, a large number of services associated to APIs have developed to cater for all the needs of companies that use them:

→ Many large firms and startups now specialize in all these domains of activity. This is the landscape of the main companies active in the API industry:

Find references for this lesson, and other lessons, here.

Discover my other courses in data / tech for business or get in touch via Twitter: seinecle www.twitter.com/seinecle[seinecle] www.twitter.com/seinecle[seinecle] et in touch via Twitter: @seinecle ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle] ter.com/seinecle[@seinecle]