Why Intellexer Runs Two Identical Versions of Its API (Including One on Mashape)

In an effort to ensure that ProgrammableWeb's API and SDK Directories are kept as up-to-date as possible, our API research team does a daily scrub-down of the Web in hopes of uncovering new APIs that we don't yet have a record of. The process is pretty straightforward. When we come across an API as a part of our daily process, we double check to see if it's already in our directory. If we have a record of it, we double check to make sure it doesn't need updating. If we don't have a record of it, we add it and also look to see if there are any SDKs that go along with it. If there are, we add those too. 

Today, in our daily scrub-down, we came across what appeared to be a new natural language processing API from EffectiveSoft. EffectiveSoft picked the Mashape marketplace as the solution for provisioning its Intellexer Natural Language Processing (NLP) API (Mashape was recently split in two; the marketplace was sold to RapidAPI and Mashape will go on to focus on the Kong open source API gateway). Whenever we think we may have found a new API, we double check our directory to make sure we don't already have a record of it. In this case, we not only found an entry for the Intellexer NLP API, we noticed that the API's endpoint (http://api.intellexer.com/) was different from the one hosted on Mashape (https://intellexer.p.mashape.com/). In other words, EffectiveSoft is running two separate endpoints for the API.

We wondered why would an API provider would ever do such a thing? It runs the risk of developer confusion, credentials for one won't work on the other, and it's a lot more work to oversee two endpoints instead of just one. So, we asked.

According to EffectiveSoft customer success manager Anastasia Hatskova, the objective is to attract more developers. The company essentially views RapidAPI's marketplace (the one that was formerly operated by Mashape) as an additional channel to reach developers. Hatskova also pointed out that through the marketplace, developers have more "integration options." What she meant is that there's support for more languages. This is an automatic outcome when the marketplace is used to describe the API in machine readable form. It's the same with APIs that are described using the Open API Specification (OAS) or RAML. Several benefits -- one of them being automatic SDK generation -- accrue to API providers who describe their APIs in machine readable form. However, as the new copy of the API was just launched this week, it will take some time before EffectiveSoft will know whether the strategy is effective or not. 

That said, I turned to RapidAPI founder and CEO Iddo Gino to ask if his company promotes the idea of running separate endpoints.  "A lot of API vendors are looking to maximize exposure to their APIs, getting it in front of more developers and making it easier for those developers to connect" said Gino.  "There are over 370,000 developers who actively use Mashape/RapidAPI, many of them have the RapidAPI SDK integrated into their apps, and a credit card on file with us."  One thing worth noting is that RapidAPI does what can best be referred to as SDK multiplexing. A single SDK affords developers simultaneous access to multiple APIs (versus loading separate SDKs for each API).  Gino noted that NeutrinoAPI is another API provider taking the same dual endpoint approach as EffectiveSoft, which ProgrammableWeb's research confirmed to be true.

Ultimately, providers looking to try dual endpoint strategies similar to those of EffectiveSoft and NeutrinoAPI should look to consolidate the paths that both endpoints take into their back-end infrastructures. In other words, all roads eventually lead to the same place. In most situations, the approach means that one of the APIs is a proxy to the other (or at least a proxy to a part of the other API's underlying stack). In EffectiveSoft's case, since the original API came before the marketplace copy, we can assume that the marketplace API is a proxy to the original stack in some way. Even so, when I asked Gino which direction he sees API providers taking, he responded that "we see developers with an existing API just listing it on Mashape. In that scenario, Mashape will proxy to the ‘native’ API. We have seen it done the other way around as well, but it is by far less common."

Finally, while we haven't seen many of these mirror image endpoints in the wild, it certainly is give those of us here at ProgrammableWeb something to consider as we continually evolve the data model for our directories. While we can shoehorn both entries into our API directory under our current data model, that model doesn't explicitly support mirrored endpoints in a way that developers would most appreciate it in terms of search outcomes. But we love it when something new comes along to challenge our conventional thinking. 

Disclosure: Mashape and RapidAPI compete with MuleSoft on certain fronts. MuleSoft is the parent company of ProgrammableWeb.

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.
 

Comments