APIs and their business relevance

EDI 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 developed a CRM as a SaaS where features of the CRM were exposed as APIs (meaning, these features could be plugged to external apps via the REST protocol). - SalesForce created a PaaS to host apps that could plug to the SalesForce CRM via the APIs developed by SalesForce. This platform is called Force.com and external developers can put their apps there, as long as they are compatible with the SalesForce API. 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: Pieter 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? Pieter 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: - more and more services are available via API. Do not reinvent the wheel, just use the APIs. - coordinating multiple APIs allows you to create entirely new services (not just: "manage my emails by API") - services like Zappier allow coordination / communication between APIs, but it also favors automation.

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?

To discover public APIs, or to make your public APIs easier to discover, you can visit https://apilist.fun/, https://apislist.com/ or https://publicapis.io. Searching on these websites, you will find APIs providing business services, or APIs of a fun or 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 bird watching? 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:

Mehdi Medjaoui from APIscene keeps an updated, searchable landscape of the main companies active in the API industry:

(or download the full size version of this poster here)