Are we already entering a marketplace or still inside a portal? Or in between.
After sharing my thoughts on API gateways and integration platforms. It is time to look at the representation of the interfaces on offer.
Specifically, representation means the use of portals and marketplaces. Before we begin to look more closely at portals and marketplaces. First, let's take a general look at the importance of representing an API. When we represent APIs, we are basically talking about the representation of the API definition. After all, the OpenAPI consists of various segments that help to gain an understanding of how the API or the individual endpoints work.
As I have already mentioned, an API definition only serves to improve understanding on the consumer side, and it is not yet clear whether the API described is also a "good" one. I have written about this very topic in various places already, so I don't want to go into depth again here. To describe it briefly, "good" APIs bring value to and for an organisation and adhere to defined standards. Because of these standards, a certain value is then also added to the presentation in the portal or marketplace. But what actually is such a portal or marketplace?
Portals and marketplaces
In the context of APIs, a portal is a central point of contact that provides developers with all the information and tools they need. This includes, for example, API documentation, test environments and developer tools. The presentation here is usually via a user-friendly web application.
A marketplace, on the other hand, is a platform on which organisations can make APIs available to offer them to others. This involves the marketing and monetisation of APIs. It is usually presented via a publicly accessible directory in which the available APIs are listed. A marketplace is often understood as the last mile in the context of the API lifecycle.
But if we get a little more specific, we not only distinguish between portals and marketplaces, but also have to include the so-called hubs. These hubs stand exactly between the two. A hub is aimed at complex infrastructures in order to make them more accessible to certain target groups. It is also a first step towards a platform. For the sake of further understanding, let's exclude the hub and put it on the same level as the marketplace.
Those who have the choice are spoilt for choice?
Again, as with the previous articles, the component, i.e. a portal or marketplace, must fit the requirements. When it comes to requirements, it strongly depends on the views that an organisation can adopt on the topic of APIs. As an organisation, it is important to consider what role you want to play in the emerging API economy in the long term. Currently, most organisations are still in a phase where they are outgrowing the clutches of traditional integration and slowly starting to share their data more consciously. Supported by APIs as a transport medium.
In concrete terms, this means that an organisation needs to look at what may exist already within it in order to take the first steps into this topic complex. Usually there is an API gateway already in place. Most of these components have a portal already on board. In this way, the APIs that use this gateway can be displayed already. Especially in larger organisations, there is not only one such API gateway. It quickly becomes confusing, as the often quoted one-stop-shop is missing.
In many cases, the make aspect is quickly thrown into the ring, since one has the highest individual demands. And one would like to assemble a solution oneself, in the case of portals and marketplaces this quickly leads to difficulties, as these require intensive further development and maintenance in order to adapt to the conditions of the respective markets. With the emerging movement of platform engineering and the so-called Internal Developer Platforms (IDPs), there is now a functioning solution in the form of a framework on the market with Backstage. In addition to possible customising, the question of how to provide such a component arises. In addition to classic self-hosting, a managed service called Roadie.io can also be used. Supported by CI/CD-Pipeline, such an IDP can be filled very specifically with the API definitions and other metadata. And thus ensures an organisation-wide insight into the APIs. With a view of the organisation's first APIs in an IDP, first of all the internal developers and perhaps the (technical) product managers are pacified. If the organisation is now thinking about taking the step of opening up more and more to customers and interested parties with public APIs. Is now also the appropriate time to move more towards a marketplace. The presentation requirements of a marketplace can then also be less technical, especially if the organisation wants to think more in terms of digital products. These products are then entering the marketplace in the form of a catalogue. If possible, they should be divided into categories. As stated already in the previous section, the main focus is on marketing and also possible monetisation. In contrast to the portal, the main focus must be on the non-technical description of the API or the service. Furthermore, the service must be packaged in so-called plans for a possible business model. This model should be extremely attractive to consumers to encourage usage. A software solution should solve both requirements in as simple a way as possible. An example of a marketplace is apinity, a SaaS solution from Germany.
Conclusion
As we have seen, it is always important for any decision in the context of APIs that the current requirements can be met. We need to think evolutionary and reconsider any decisions made when they no longer fit our current situation. In the context of portals and marketplaces, this can mean that we have to take a close look at the status of the APIs. In the case of so-called private and internal APIs, the benefit of a marketplace is rather low, as here the focus is still on technology and the main consumers are developers. If we are really talking about a public API, then it is time to think about a marketplace or an extended portal, e.g. an overarching hub.
