Public API

_{Published: 26 January 2024}

Known Uses

Public APIs are open and accessible to anyone who wants to use them. They are often free or have low fees. The goal of Public APIs is to make consumption easy and, very often, to attract as many consumers as possible. Obviously, there are many Public APIs offered in the Dutch Dutch Government Public sector, and they are available and discoverable via public developer portals like:

• https://developer.overheid.nl/
• https://aandeslagmetdeomgevingswet.nl/ontwikkelaarsportaal/api-register/

In these cases of open government data scenarios, very often the Retrieval Operation pattern is applied. In the Dutch Energy sector, there are fewer Public APIs. Some examples:

• https://www.eancodeboek.nl/ With the help of this service, one can look up a ‘connection identification code’ (EAN code) for a connection to the electricity and gas networks in the Netherlands.
• https://energieonderbrekingen.nl/api/v2/ Real-time information about gas and power outages. Collaboration of three Dutch grid operators: Enexis Netbeheer B.V., Liander N.V., and Stedin.

There are various ways to categorize and classify APIs. Commonly used is the classification into public, partner, and private. The Dutch government uses the classification internal/external and the further subdivision external/open and external/closed. The latter corresponds to the partner or community classification. See https://geonovum.github.io/KP-APIs/API-strategie-algemeen/Architectuur/#typologie-van-api-s.

It is very well stated in the book (page 49): ‘…the difference between a Public API in general and its Open API variant: a truly open API is a Public API without an API Key or other authentication means…’. See also: https://nordicapis.com/6-types-of-apis-open-public-partner-private-composite-unified/

Discussion Input

Figure 4.8 on page 142 illustrates a Public API in context. It shows a public API with three different consumers: 1) Web App 2) Mobile App 3) Third-Party systems. Within Enexis, we experience different API requirements from different consumers. For instance, frontend-oriented consumers might require form-like API data models that resemble web-forms, whereas Backend systems might require more detailed or generic information. These different requirements can be incorporated into a single Public API. However, the potential risk is creating cluttered APIs with redundant operations and data. How should we manage the requirements of different consumers? When is it justified to fulfill the requirements of different consumers in multiple Public APIs?

Recommended Reading

Designing Private, Partner, and Public APIs: What’s the Difference? (Erik Wilde): https://www.youtube.com/watch?v=HmIHw3U5jEQ