Before explaining about the evolution of the API marketplace, it is better to clarify the differences between an API portal and a marketplace first. This shows how a marketplace adds value to the web developer experience.
API portals have become a staple of the API Economy for several years. Through portals, users can deliver API documentation and include features like interactive explorers and tutorials. Moreover, developers also can securely onboard with the API provider by creating API keys or OAuth credentials.
On the other hand, marketplaces aggregate many API providers into a single view and typically add search function which makes it possible for developers to browse many different APIs. Usually, APIs are classified based on its area of focus, such as finance, social, accounting, etc.
Marketplace offers you with better simplicity where developers can come to one place for the majority of their needs as an API consumer. As a result, developers only need to do integration across many API providers. The approach also has positive effects for API providers. For example, it can increase exposure for their APIs, especially for developers and smaller providers without huge presence.
That being said, however, how do developers differentiate between similar services to find values if many are competing for API providers? So, how do you make your API offerings stand out in the crowd? It will surely be difficult to know which payment APIs in the marketplace that is the best among so many payment APIs. This is why we need an evolved API marketplace as a solution that can solve this problem.
Benefits of an Evolved API Marketplace
You can take a look at an evolved API marketplace that has three key features which differentiate it compared with current offerings:
- An improved classification system that helps building a more sophisticated view of the APIs in the marketplace. This system will increase the contextual or even semantic search capabilities.
- Support for search by applications as well as humans which means providing a search API – REST, GraphQL, or otherwise – that can be used to interrogate the marketplace.
- Support for integration at an application level i.e. an API can be selected from the marketplace based on the search results and integrated with automatically.
The functionality above offers you with many benefits. For example, users can have more relevant and specific search results that guide them to the API with the features they really want. Besides, consumers will also be able to automatically onboard and try out without having to rely on manual steps across many different API providers. As a result, this will reduce lock in for API consumers and offer real choices in the market place.
So, how about providers, do they have any benefits for API too? Users will be able to market their APIs based on the same attributes that API consumers and their applications can search on. This approach levels the playing field for API providers. Furthermore, to get competitive advantage, providers will also be able to interrogate the marketplace and look for ways to remodel their offerings.
Example
In this example, the scenario is a foreign exchange platform which is automatically searching our marketplace for a foreign exchange API with some given criteria, namely a per click fee of 1% of the value of the transaction and a supported throughout of 1000 TPS.
To search for such a provider, the foreign exchange platform submits the following query at the GraphQl endpoint:
| 1
2 3 4 5 6 7 8 9 10 |
{
Apis(filter: { subject: FX, feeType: per-click, chargeThreshold: 1% }) { name specification } } |
The result returns an API provider, RightONFX that has matching attributes and a link to their Swagger specification.
| 1
2 3 4 5 6 7 8 |
{
“data”: { “Api”: { “name”: “RightOnFX”, “specification”: “https://rightonfx.nowhere/swagger.json” } } } |
This application, which is based on the OpenApi specification, detects that the specification included is a well-known endpoint that conforms to the OpenID Connect Discovery Protocol:
| 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
{
“swagger”: “2.0”, “info”: { “description”: “The RightONFX API”, “version”: “2.0”, “title”: “API Explorer” }, “host”: “https://rightonfx.nowhere” “basePath”: “/”, “consumes”: [ “application/json” ], “produces”: [ “application/json” ], “paths”: { “/.well-known/openid-configuration”: { “get”: { “responses”: { “200”: { “description”: “OpenID configuration information” } } } } } } |
The protocol above permits configuration information about an OpenID provider to be retrieved by potential clients and includes the endpoints that allow a client to know how to register as an OpenID client of the provider.
Final Thoughts
Simplicity and choices are still important factors for many API consumers. Therefore, software solution providers in general are coming with solution of producing jigsaw technologies that can be easily assembled into a solution. With this movement, reducing integration headaches for API consumers is consistent with this movement, and API providers will receive it as a sign to sell their product.