People love marketplaces. Offline, at the winter fair or at the souk, marketplaces provide consumers with the ability to browse for the goods they like and haggle over the price. Who doesn’t love a bargain? Online marketplaces like price comparison websites retain this tradition, allowing consumers to find the best deals for insurance, credit cards, and so on.

With the rising significance of API directories, it makes sense that developers too should have a similar marketplace experience for not only discovering APIs, but finding the most cost effective bargain for their choice of API features.

API marketplaces like RapidAPI, Hitch, and API List allow developers to browse for the APIs they want to consume. On these aggregation sites, visitors can often learn about API functionality, test calls, and enroll with a myriad of API providers.

However, this is only one side of the appeal of an evolved API marketplace. For developers to get the most bang for their buck, will they ever be able to haggle over the price on these sites? How will these directories evolve to server continued nuanced developer needs?

In this post we look at how API marketplaces might progress and whether they will truly deliver increased choice for API consumers.

Portal vs Marketplace

Before talking about an evolved API marketplace it’s worth clarifying the differences between an API portal and a marketplace. This will emphasize how a marketplace adds value to the developer experience.

API portals — whether a homegrown effort or a template-based API management product — have been a staple of the API Economy for several years. Portals are deployed by a single API provider and allow developers to understand, integrate with, and deploy against the provider’s APIs. They deliver API documentation (generally in conjunction with an API specification) and include features like interactive explorers and tutorials. They also allow developers to securely onboard with the API provider by creating API keys or OAuth credentials.

Marketplaces differ from portals as they aggregate many API providers into a single view and typically add search functions so developers can browse many different APIs. APIs are often categorized by area of focus (Finance, Social, Accounting, etc.) Mashape is an example of this kind of functionality:

The attraction of using a marketplace is one of simplicity. Developers can come to one place for the majority of their needs as an API consumer. This attraction is piqued with added value features like webhook aggregation (as recently released by RapidAPI), integrated API onboarding, centralized support, and issue tracking. By using these features developers only need to do one integration across many API providers.

The approach also has positives for API providers. Being part of a marketplace can increase exposure for their APIs, especially for developers and smaller providers without huge market presence. For some providers, deploying to a marketplace can mean dispensing with a portal altogether — they simply need to provide an API specification and they are off-and-running.

However, if many competing API providers participate in marketplaces, how do developers differentiate between similar services to find value? And on the other end, how do API providers make their offerings stand out in the crowd? For example, if there are 10 payment APIs in the marketplace, how does a developer know which one is best? This is where the idea of an evolved API marketplace starts to take shape.

Benefits of an Evolved API Marketplace

An evolved API marketplace would have three key features that differentiate it compared to current offerings:

• An improvedclassification system that helps build a more sophisticated view of the APIs in the marketplace. This system would enable contextual or even semantic search capabilities.
  * Support for search by applications as well as humans. Ultimately this 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.

This kind of functionality has many benefits. For consumers, there is obviously the increased choice by way of having relevant and specific search results that guide them to the API with the features they really want. Looking for APIs with a specific price plan, subscription model or otherwise will be much easier. Moreover, consumers will also be able to automatically onboard and try out APIs without having to rely on manual steps across many different API providers. At its most sophisticated this might mean that API consumers can perform just-in-time onboarding in reaction to changes in the marketplace such as price cuts or promotions. This will reduce lock in for API consumers and offer real choice in the marketplace, with the ability for applications acting autonomously based on the intent of their creators or on market conditions.

There will be benefits for API providers too. They will be able to market their APIs based on the same attributes that API consumers and their applications can search on. Choosing an API will therefore become more a case of the features of the API as a product rather than picking an API based on the technology implementation. This approach levels the playing field for API providers. They can compete on the attributes of their product and not the vagaries of subjective judgements by developers and their view of technology choices.

Providers will also be able to interrogate the marketplace and look for ways to remodel their offerings to get competitive advantage. While such capabilities have their threats, for the brave it means really offering customers what they want by understanding their intent more deeply. Running a promotion on your API — in the same way companies do with physical products in a brick-and-mortar store — becomes a real possibility.

Example

It’s relatively straightforward to put together a prototype of one aspect of the evolved marketplace; that of automated discovery and enrollment. This can be done using existing technologies and protocols.

In this example there is no specific API marketplace product as we’re assuming one of the products we’ve already mentioned could be engineered to support this.

In this prototype four key components are deployed:

• An API marketplace with a GraphQL endpoint that allows API consumers to query for the type of API they want to utilize.
• An OpenAPI specification describing a foreign exchange API that includes a well-known endpoint.
• An implementation of an OpenID Connect Discovery endpoint.
• An implementation of the OAuth 2.0 Dynamic Client Registration Protocol.

Note that for brevity this prototype intentionally ignores the mechanism for classifying APIs in the marketplace.

In this scenario a foreign exchange platform 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 throughput of 1000 TPS. Such an API would offer the application owner a cost reduction which would in turn allow them to offer keener prices to their end consumers.

The foreign exchange platform submits the following query at the GraphQL endpoint to search for such a provider.

{
  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.

{
  "data": {
    "Api": {
      "name": "RightOnFX",
      "specification": "https://rightonfx.nowhere/swagger.json"
    }
  }
}

The application generates itself a client based on the OpenAPI specification. It also detects that that the specification (abridged version shown below) includes is a well-known endpoint that conforms to the OpenID Connect Discovery Protocol:

{
  "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 Discovery protocol allows configuration information about an OpenID provider to be retrieved by potential clients and includes the endpoints that allow a client to how to register as an OpenID client of the provider. The marketplace grants the application a temporary token to access this endpoint and the registration endpoint it describes.

Using the token, the application then uses the Dynamic Registration endpoint defined in the well-known configuration to register their application as an OAuth 2.0 client. The registration request returns a client ID and client secret. The aggregation client now has everything they need to start making requests to the RightOnFX API.

Final Thoughts

An evolved marketplace for APIs appears to be a logical progression for the API Economy. Some may argue that this style of marketplace is an aggregation layer for APIs that is against everything the decentralized architectural style stands for. An evolved marketplace will also require a fair and equitable classification system that prevents hegemonistic practises (on the part of the API marketplace provider) creeping in and reducing consumer choice.

In our example the search criteria are fairly unequivocal but if semantic search is relied upon there is the potential for subjectivity to creep in when the search terms are interpreted. There is also the challenge of coming up with an accepted classification system, something that has been difficult in internet communities before.

Our prototype obviously has its flaws, most specifically in how the generated client is integrated into the foreign exchange platform and whether terms-and-conditions are accepted (step-up RegTech to provide this at a machine level). However it shows how easily an automated provisioning approach, driven from an API marketplace could be constructed based on available technologies.

Many API consumers welcome choice and simplicity. Software solution providers in general are meeting the demand for ease of use by producing jigsaw technologies that can be easily be assembled into a solution. Reducing integration headaches for API consumers is consistent with this movement, and API providers will embrace it as a means to sell their products more readily. Such an approach can only benefit the API Economy and its continued growth.