Glorified API catalogues

Some measure the growth of API economy by looking at the stats and charts in API catalogues such as ProgrammableWeb. These catalogues list public APIs which someone has bothered to register. The catalogues provide some idea of the amount of APIs, that’s about it. They have little value for the daily developer work. In my opinion the catalogues are more like marketing stunt nowadays than something else. Of course they promote and enable some level of discovery of APIs so they are not worthless. For long I thought that API catalogues are one of the biggest things in API economy.

After being around the topic for some years, I’ve come to different kind of opinion. API catalogues are nice - for marketing people. API catalogues are nice - to say “look! Our API is there. Now ddevelopers will buy our services/API!”. For the record, I was just sarcastic with the last statement. Lately I have become puzzled with the glorification of API catalogues.

So the API catalogue becomes a simple jump point on the developers’ customer journey. At the same time I have fallen in love with the notion of libraries after studying some of the success stories in API economy. I’ll come to those a bit later…

Are package operators key ecosystem players?

If you are creating APIs driven tool or service to be used in application development (or alike), add your APIs to catalogues. Not a big effort, but that alone is not going to be enough. You need to maintain the information as well. As long as the API catalogues are not maintained directly based on machine-readable spec files (or alike), something is certainly outdated and provides false information. At least I was not able to find API to add, update, remove APIs in ProgrammableWeb. I was able to find a frigging form. Dispite of the nagging I still consider API catalogues to have some value in API Economy. I’m not sure if they are much value to developers, but for some they are.

Developers want ease of use, instant value, instant usage from own code. That’s where the package registries become handy. NPM packages are installed from command line, which is the must have environment for all developers. Even “spaghetti code warriors” like me find it extremely useful.

With simple search command npm search stripe you get needed listing and details of available packages

Next step is to run for example npm install stripe. After that developer can use your service from own code. Of course they need credentials but those are acquired from Stripe’s portal, not from API catalogues. Even I can do the above and I’m only “spaghetti code developer” not a proper developer.

If the library is added to a open source product distributed via Github, your API product gets free promotion. In those cases it is added to package.json file and all needed dependencies including your library are install with simple npm install command. Neat! Your product is distributed to developers by other developers. In these cases be sure to have preemium plan so that new developers can see the value of your library before committing to it.

Yes, some developers spend a lot their time in IDEs and even some of those enable package installation with ease and without need to visit any frigging websites. Now think again. Do I expect my consumers to search my libraries or other tools from Google or do I provide methods to achieve developer’s goals from within their normal tools and environments? Considering the fact that quite often developer is given most of the tools and services to use. In those cases they don’t browse API catalogues, but install the needed tools with minimal effort. It’s not that fucking hard, you know.

Of course the above straight forward approach pretty much assumes that the developer expects or hopes to find a library from the registry. If that is not the case, developer seeks for information probably from google and might end up in API catalogue or directly (mostly this is wanted) to your site. Eliminating the extra visit at API catalogue is making the developers life easier.

The API catalogues were just one passing phase in the growth of API Economy. Those can be used to check if an API exists for some use and possibly get some ideas, but that’s about it. No wonder API catalogs have started to include more content and services next to the plain catalogue. Otherwise they would just vanish.

Library is needed or not

If your service is simply used via one API which has profound documentation, pricing plans, code examples and it solves a problem you don’t need a library. The more complex thing you are trying to solve, the more APIs you most likely need. Then it makes sense to package all API capabilities behind one library. Service provider might have single APIs for specific features (like Twilio), but it’s just so much easier to take advantage of the offering by using a single library.

Package registries

Successful code libraries and components are productized just like APIs and you should take advantage of the distribution channels such as npm (javascript) and pypi (python). Npm alone serves over one billion requests for JavaScript packages per day to approximately 11 million developers worldwide.

Pypi serves around 80 million requests for python packages per day. As an example, AWS command-line interface (awscli) and Amazon S3 Transfer Manager for Python (s3transfer) are among of the most downloaded packages in Pypi driven Python ecosystem. As we all know, AWS is APIs driven as result of famous API Mandate by Jeff Bezos.

This takes us to an interesting hypothesis:

if significant amount of NPM and pypi packages are libraries which use APIs, then the package registries are huge enablers of the API economy, bigger than famous API catalogues such as ProgrammableWeb. If the hypothesis is true, then the true impact of API economy can be measured with help of the code libarary distribution stats.

Of course this hypothesis should be confirmed by analyzing the libraries and components disctributed by npm and pypi to see which amount of those packages use web APIs behind the scenes. It would also be interesting to see correlation between popular APIs in catalogues and libraries in code package ecosystems.

Libraries-driven API economy?

Some of the biggest success stories of API economy are Stripe, Twilio and AWS. They do not push raw APIs to application developers. Instead they rely and promote use of command-line interfaces and libraries. With help of these ready-made packages any application developer can utilize API driven services (among other things) more easily and with only a few steps. This was discussed in details previously.

In the above screenshot is the famous “5 lines of code” Stripe library example. Of course the above is more of marketing and sugar coating than practival tool for daily usage. It’s a showroom for Stripe’s APIs driven product. Again in the example above library const stripe = require('stripe') is used rather than raw APIs. The example uses NPM package which is the library (“stripe”).

Twilio has 40 000+ customers and create 400 million revenue with 5+ APIs. Stripe has around 100 000 customers, handles 100 billion worth transactions and creates 1,5 billion revenue with 1 API.

Conclusion

So it seems that with complex API products which contain a lot of endpoints or multiple APIs, productised libraries are a key method to provide easier usage of the product. If the API product is simple, library development (and maintenance) might be waste of time. In both cases it might make sense to add your API product to all major API catalogues if you are ready to maintain them manually.

Some more to read from 100 Days DX