What is an open API - or what makes an API widely adopted?

It is very demanding to establish an unambiguous definition of an open API. The discussion quickly turns into a value debate and a setting of objectives instead of a 'dictionary’ definition. In English, the word Open API has had a very different background and purpose than, for example, open data or open source concepts.

You get what you order. Do you want the API to be used by the widest range of consumers producing an impressive result? Then you need to pay attention to how the API is provide and acquired. Especially if you order development work, product, or technology that includes APIs. The legal terms and conditions play a key role in the openness of the API. 

The objectives of public versus private sector may sometimes seem contradictory, when it comes to openness of APIs. Public sector and non-governmental organizations have lately been enthusiastically driving for open data services,. This is due to transparency requirements, but also to avoid vendor locks.  The next step from there is to develop applications as open source code and then to serve the open data via APIs. It seems logical that if open data and open source can be used widely and mostly for free, depending on the open license chosen, then why not “open APIs”. But this is the trick, even if open data, open source, and open API have all the word open in front, they historical development has been different.

Why choose an open API?

Often, the point of providing an API is to increase business or societal benefits. This typically requires the API to be as widely adopted as possible. While all of the reasons below make sense for external APIs, often called public or partner APIs, many make sense for internal APIs, too.

A widely adopted API enables:

• cost-effectiveness,
• the speed of development and change,
• ease-of-use and, in particular, the emergence of a network impact, and
• supporting an ecosystem with the same objectives,
• increasing market share or impact

‍

Your API will be widely adopted if…

There are several ways to achieve your API will be widely adopted. One way is to standardize the API, which may be a slow process. Another option is to create a so-called de facto standard. This means ways to ensure that the API is adopted by a large and growing group of consumers.

Only by implementing an easy to use, well-documented, error-free, and sufficiently well-functioning API, its use can be expected to increase. In addition, to get the API widely used it needs the same things as open source software:

• Open team of developers
• Open procedure for reporting development ideas, errors and support requests
• Transparent roadmap
• The possibility to influence the decision-making in development. 

The more open an API is, the better it fills these requirements, too:

• Adequate level and promise of service
• A common technical implementation of the API
• Publicly available standards-based API description and other documentation, and
• Comprehensive marketing and communication, so that information about the API reaches potential consumers
• Ideally, the API documentation should be published so that viewing it or assessing its usability does not yet require a contract or the acceptance of contractual terms, or requesting access rights.

If all interested third parties have access to the API, the term public API is often used. If only selected parties outside the organization are allowed to use the API, the term partner API is used. In addition to these, different parts of the organization can provide APIs for themselves and each other, in which case they are called internal APIs. In many sources, open APIs are defined as public APIs. Some sources also include partner APIs. (Moilanen, Niinioja, Seppänen, Honkanen, API economy 101, 2019)

‍

Increasing openness with open licenses and standards

The openness of the API can be enhanced by openly licensing the data models, documentation and instructions. Also, the API should use standard data models where possible.

The use of open licenses and standards is particularly important if the wider use of the API also requires parties to copy the API over their own information systems and technologies. This is typically related to open source software that includes an API. Simply copying the API interface definition or data model is not sufficient to ensure that the copy of the API functions in the same way or that the future versions will be compatible. Joint or integrated technical implementation, as well as an open team of developers, may matter more than open licensing on its own.

Open licensing may contribute to the formation and interest of a team of developers. If the entire system's source code is licensed under an open license, the resources associated with the API may be included in this license. If the software or other technology implementing the API has been copied, the terms of use of the data can be completely separated from the terms of use of the API. This means API is operated by each consumer in their own network, in their own devices, or cloud under their own control. Also, the API is interacting with its own resources (data, buildings, algorithms, etc.).

‍

Is the data provided or received by the open API always openly licensed or free?

Not always, but there could be more opportunities than you think. For example, tax information reported by companies to the tax administration through APIs is not, as such, public data. The API might be openly available to all companies providing services to other companies or for their own use. However, some of the data can be published, for example, as open data under the Publicity Act or other legislation relating to tax information.

If the API consumers are in fact SaaS users and are paying for the software subscription, the data they use through the API is “their data” and “free” in the sense of they are not specifically paying for the API or using the data via the API. But they could, depending on the terms and conditions. And they may have restrictions on how much data and how often they are allowed to request without paying extra. 

‍

Is the open API always free of charge?

Open data and open source code are often thought to be free of charge. Some definitions also allow a reasonable fee to be collected in order to open the data or source code. However, it is essential to separate the data and the source code from the API itself.

A free or affordable API is certainly more popular and more widely used than an API with a fee. There are always freemium options, where you have an amount of time or a request limit that is free. 

The main take-way for the differences between open data, open source code and open API is that an open or “closed” i.e. public, partner or internal API can be built on open source code (or not). It can offer the data with open license - or not. The interface description of the API and the documentation may be licensed with open license - or not. Depending on the industry standards, legislation, the use cases, and the community expectations the best choice is to be as open as possible, but to remember the realities. Someone needs to be able to pay the bill in the end.

‍