Apiida
Company
Consumer Experience is key when managing APIs across multiple vendors
Consumer experience is a key driver for API adoption
The consumer experience (or developer experience [DX]) is one of the key drivers of API adoption, usage, and low error rates. Especially in an agile, product-led environment, easy-to-use and easy-to-implement APIs are crucial. These environments require fast feedback cycles from idea to delivery in order to fully exploit the potential of this way of working.
Traditional full-lifecycle API management platforms provide a solution for consumers to discover APIs, read their documentation, and sometimes even test drive APIs in a sandbox.
However, the solutions are usually limited to the APIs running on this very platform. Now, what if you have more than one platform? Maybe you are currently building your new all-in integration platform but still, have to support a legacy one in order to access some services and their APIs?
In this article, we will take a look at the difficulties you face when you try to unify your developer experience and how APIIDA’s products will help you with this endeavor, and how they even are increasing your DX notably along the way.
What is a good consumer/developer experience?
In order to build innovative new experiences or optimize existing processes, developers need to be aware of which APIs are available and how they are implemented.
This is called API discovery. In full life cycle API management platforms, the component, that takes care of discovery is often called a developer portal. This developer portal hosts the API catalog, which contains all the APIs the developers have access to.
Common features of these portals include:
– A searchable API catalog
– Access to the specs of the API (Swagger, OpenAPI, AsyncAPI, ..)
– Documentation on how to use and what to expect
– Code samples or SDKs
Besides these features, the developer portal also allows developers to get access to an API. In order to enforce usage quotas and collect usage data for later analysis, every application that wants access to an API needs to be registered. The developer portal usually provides these applications an API key, that they need to present in order to access the API.
Good developer portals should provide the following features:
– Request access to the needed APIs
– Request new API keys for APIs applications that are already subscribed for
– The ability to disable API keys in case they are compromised
While good documentation and an easy, fast, and self-service-based way to get access to an API are the foundations of fast implementation and adoption, there is one other area of features, that distinguishes good from great developer experiences: Testability.
Developers who are new to the API or the domain that this API models, learn faster if they can issue test calls to the API. This helps to learn how the API is structured and how it behaves, for example, in case of an error.
Such sandboxes usually provide the following features:
– An separate testing environment to run calls against
– A mocking service, that creates valid responses
– A mocking service, that is capable of also creating wrong responses or error conditions like a non-available backend
For a more in-depth look at developer portals and a comparison of the portals of different API management platforms, make sure to regularly look at our blog or subscribe to our newsletter.
Why do you even need a unified experience?
Implementing or adopting an API is not an easy feat. While the majority of APIs are built based on a common understanding of how an API should look, there are almost no two APIs that really work the same way.
If your consumers, the developers, have the option to choose between two APIs, that provide similar functionality, they will choose the one, that is easier to implement, has better documentation, and is actively supported by the publisher. This means that having a great developer experience translates into a competitive advantage! Changing API providers down the road is highly unlikely and requires a huge investment and a lot of effort on the consuming side.
Apart from the advantages for external developers, internal developers benefit from a company-wide API catalog, too. The easiest and best way to differentiate from the competition or to improve existing processes is to build on what is already there. Companies might build new digital offerings by combining data and APIs that are already present but haven’t been used in such a way yet. To achieve that, the cataloging of all the data and APIs is the very first step. Coupled with the ability to instantly get access and test drive these APIs, this is the foundation needed for agile teams to perform at their best. Agile teams rely on fast feedback cycles, constantly validating their hypothesis on the viability of their idea.
No matter if external or internal developers, one challenge remains: You need to be able to compile your API catalog in a way, that really does capture all of your APIs.
Some APIs might already be managed with a full life-cycle API management, while others are not managed at all. REST or SOAP-based APIs need to be captured as well as event-based APIs common in business processes or IoT scenarios. The developers don’t care about which platform the API is running. They don’t care what operations need to be performed in order to generate and authorize new API keys. And they shouldn’t have to. Forcing developers to check multiple places for APIs they might need to work with, with inconsistent documentation standards and ways of getting access, is a really bad developer experience, that will hurt adoption and, ultimately, the business itself.
The solution to this problem is a unified developer portal, that collects the APIs from all the different sources and offers a standardized way to categorize, link, and document them. Making it easy for the developers to discover, test, and implement the APIs. All the hassle of connecting multiple systems and taking care of registering the consuming applications at the underlying platforms is something that can and should be handled in a productized and automated way.
How autonomous API management helps!
Autonomous API Management splits the management part from the execution of the APIs. The details of APIs that you have already published are automatically imported and kept up-to-date. This works across all of the supported platforms and even uses raw git repositories as a data source. This combined view of all the APIs of a company is then used to build a comprehensive API catalog. On top of that, APIIDA provides you with one of the best experiences for developer portals out there.
“Naming is hard!” is one of the basic truths of software development. Names and concepts should be as clear as possible without ambiguities. When trying to find these unambiguous names, different people come to different conclusions. This is the reason why even for similar concepts, their names in different API management platforms might be completely different. While an API proxy in one platform is the software flow protecting and transforming requests to the backend system, it is the name for the whole API gateway in another. This is highly confusing for all people that are required to work in all of these systems, resulting in a higher cognitive load and less performance.
APIIDA’s independent (or autonomous) API management unifies the different concepts and different names under one easy-to-use, easy-to-understand concept. We automatically do the needed transformations into the platform-specific concepts. In case you need adjustments, we can just change our adapters and make it work for you. APIIDA’s solutions are extensible by default.
Use the best tools
There are a lot of great tools out there. However, connecting them in a working and meaningful way isn’t always easy. Because of this, businesses sometimes stick to worse but better-integrated tooling. Especially full life-cycle platforms tend to bring their own versions of popular tools instead of just using what is there.
APIIDA’s solution is built on the concept of composition. This allows us to incorporate the best tools out there.
Any necessary transformation to make the tool work is done by our system.
Extensible and future proof
APIIDA’s products are developed API first, and we develop in the open. There are no private APIs or undocumented stuff. This means that our standard developer portal uses the very same APIs you can use, too. This allows you to either use our solution or build a totally new and unique experience yourself. To give you a head start, the code of our developer portal is open source and can be forked and changed by our customers at will.
