API Products is a word we see more and more often in the API world. Like any other product, an API Product provides a service and solves a specific API use-case. It is understandable by its users and makes their consumption as easy and efficient as possible.
In a previous article, we defined what APIs are and illustrated them. Yet, since the Blobr team is fond of APIs comparisons, let’s add another one to our literature. Remember, an API is a software intermediary allowing two applications to exchange data. Well, let’s imagine a river and roads on both sides. For vehicles to go from one side to the other, they need to cross the bridge. With the bridge, one can control the traffic: no more than "X" cars on the bridge per hour, no car crossing the bridge without paying "Y" euros. APIs can be compared to the bridge allowing different applications to exchange data with one another. That exchange can be controlled and monetized.
Now, what's a Product? A Product is any good, service, idea that can be offered to a market to satisfy customers’ wants or needs. A good API Product solves a real pain for a specific use case, is understandable by its users, making their consumption as easy and efficient as possible. The more the API Product is used, the harder it becomes to part with it, because of the strategic or monetary value brought to the business.
To answer that question, let's deep dive into the API audience and its goals. We have two different stakeholders.
APIs Providers:
Stakeholders at an organisation exposing data through APIs to API Consumers. Their goal is to build an API that answers their customers' need with a small technical debt (time spent on API development, API maintenance, bug fixing...) They see their APIs as long-time value enablers either through API monetization or better ecosystem development.
APIs Consumers:
Stakeholders at an organisation consuming the data shared from an API Provider. Their goal is to access data that meet their requirements, are easy to consume and integrate into their own applications. They want to get a short time to value using the API.
There is a tension between the objectives of API Providers and API Consumers. API Providers want to build an API with the following attributes in mind: consistency, usability, availability and performance. In summary, a logical access to data.
It is super hard to make it compatible with an interface to fulfill the needs of API users. A critical mistake in API design is to make decisions based on how the underlying service and technology work, rather than what the API Consumers need. APIs may look simple to implement and support but will definitely be hard to use. The best design is produced when you understand how the API will be used (use cases) so it is baked-in the way you build the API.
However, if you go this route, it means that you multiply APIs and for each API you need to get a product approach first representing one use case each. The cost to create and maintain API products becomes prohibitive. You need to get a large group of people (Product, Business and Dev) onboarded from day 1 to define an API.
Today, we can say it is the API Consumer. We see a lot of API Providers having issues implementing their customers' use cases. That results in API Consumers having trouble implementing the set of endpoints.
API Providers' side:
API Consumers' side:
With that in mind, let's get back to our bridge story. Let's recall the best bridge experience you ever had: strong steel bridge, blow-minding structure, solving a real pain of yours going from one area to the other, clear signage based on road conditions and traffic, fair toll for the service delivered, etc...This bridge is the API product every API Provider should aim to build and every API Consumer should aim to take. An API becomes a real product when it is not only exposing two pieces of software but rather when it is designed for a user-friendly consumption.
Thanks to our unique no-code techno, Blobr helps API Providers to dispense the best experiences to API Consumers while keeping their API structure simple. We give superpowers to Product Teams so it reduces product complexity induced by traditional API creation.
Looking to move up your API strategy? Get in touch with our team.
