For quite some time now, the topic “API as a Product” has been appearing in various media. But what does it actually mean?
If you look at APIs, the focus is often on the technical implementation, whereas the view of the business is neglected. Increasingly, however, more and more offerings are being created precisely in this context. So we should start to understand APIs as more than just a product. Today we use them as a service to give a user the possibility to access core resources of a business with low risk and costs. In this respect, we should also see an API less as a pure code base and more as a part of the business assets, since it is exactly with this API that we generate corresponding operational values.
If we integrate the business aspect, we should take a closer look at some terminology from this context in connection with APIs.
As a first step we assume that we basically develop APIs as if they were publicly available, i.e. Public APIs. This assumption forces us to make sure right from the beginning of development that the API is easy to understand and use for every potential consumer through good design, implementation and documentation.
The role of the consumer in the API environment
We are dealing here with two types of consumers, the internal and the external. The external consumer is someone outside the actual business. It can be a specific user or a provider of another service. The internal consumer is part of the business. For both types of consumers, the internal consumer is usually a developer. From a business perspective, there is a corresponding value behind every transaction, whether internal or external. Thus, the API is to be seen as part of the value chain.
After dealing with the consumers, we should turn to the development of an API product. Development is basically a process that incurs costs and therefore represents an investment. This should be kept in mind when considering APIs in terms of a product. Before the concrete implementation is started, an MVP (Minimal Viable Product) is defined for the API product. This then includes a roadmap to guarantee that consumers get exactly what they really need. By this limitation within the development we prevent the implementation of features that are not needed, such as unused endpoints. Potential security gaps are thus reduced.
What you should never forget when developing an API is the immutability of the API. In the sense of the product idea this means that corresponding changes must be downward compatible, otherwise investments in the product are not reasonable.
Now that we have developed an API product and made it available to consumers, the question of the value of the product quickly arises. Here it is necessary now to measure or make measurable the use of the product accordingly. In this way, the business value of an API product can also be brought closer to a non-technical audience. For this audience, however, the number of APIs within the product is not decisive.
Here are some questions for the development of potential metrics:
- How long does it take to register to use the API?
- After how long does the user receive the first 200 response from the API?
- How often has the API been shared across social networks?
- Another important aspect of measurability is the continuous influence on the roadmap, as we now have a direct feedback loop to the consumer.
Availability and publicity
To make an API product available and known to consumers, a developer portal is often used. This portal enables consumers to learn about and use the offered API on their own.
Safety is also an important factor for API products. They should therefore be protected by OAuth, API Key Verification, XML/JSON Threat Protection and general security mechanisms.
In order to establish an API as a product within the digital transformation of a business, we must keep the above-mentioned points in mind during implementation. After all, the product ensures that applications and systems can be connected to each other from anywhere and at any time.