This post comes from the SDK Bridge newsletter. I find so much value from what Peter and Jonathan do over at SDK Bridge, I always have to post their newsletter here and share with all of you.
ProgrammableWeb is known for publishing the number of public APIs in its directory, and they regularly present an impressive graph that shows how this number has increased exponentially over time. However, not all APIs are public, and ProgrammableWeb is not able to obtain information on how many non-public APIs exist.
SDK Bridge writes API documentation as a service, and many of our customers have us document their non-public APIs. That puts us in a unique position to be able to estimate what percentage of APIs is public compared to non-public.
What exactly is a non-public API? For the purposes of this article, let's define a few terms.
Public API. A public API is an API where the documentation is freely available on the Web. Using the API may require registering and paying a fee.
Partner API. A partner API is an API where the documentation is not made available to the public, but is made available to select companies who have some kind of partnership agreement with the API provider. Typically the documentation is accessible through a password-protected website.
Internal API. An internal API is an API that is only used by developers who work for the company that provides the API. Typically the documentation is available only on an internal website.
Since its inception in 2008, SDK Bridge has written documentation for 23 web APIs. (Web APIs are only a portion of the writing that we do for software professionals. We also write SDK documentation, IT documentation, and training curricula, as well as create video tutorials for developers.) Of these APIs, 12 were public, 9 were partner, and 2 were internal. The following pie chart shows the breakdown:
|Web API documentation by type.|
For the non-public APIs (partner and internal), it's interesting to note that 82% were RESTful and 18% were SOAP APIs. Also, 91% supported XML formats and 18% supported JSON formats. This suggests that non-public APIs have mostly made the transition from SOAP to REST, but have largely not made a transition from XML to JSON.
Our data analysis indicates that roughly half of web APIs are not public. Two factors to consider:
- The sample size is still fairly small. As time goes on and we get a larger sample size, we will improve the accuracy.
- Companies may be less inclined to hire outside writers for non-public APIs than for public APIs. This means that our data could easily result in an underestimation of non-public APIs.
However, for now, if you are looking for a rough estimation of the total number of APIs, you can take the number published by ProgrammableWeb and double it.
|Internal APIs, Peter Gruenbaum, ProgrammableWeb, SDK Bridge|
blog comments powered by Disqus
Latest Blog Posts
- Quick Demonstration Showing The Benefits of The White House Digital Strategy
- IRS Needs To Use White House Open Data Policy For Guidance
- Dropbox As Your Apps Default File System
- DataSift's Open Source World
- Salesforce Adds Sandbox Templates
- An Open Source Code Catalog for your API
- Multi-Tenancy with WSO2 API Manager
- Ember, Angular, Backbone, Single Page Applications and APIs
- APIs in DFW
- Adding API Broker Under Monitoring for API Aggregators
- The Dark Matter That Make APIs Work
- Potential for API Aggregators to Provide Valuable Industry Data
- My Talk Tomorrow Night at the Dallas-Forth Worth API Professionals Meetup
- The White House Releases An Open Data Strategy
- When API Success Signals Begin Working Against You
- Get To Know Which Languages Your API Developers Are Using
- Twitters Developer Area is More Embeddable Than API
- Overview Of Backend as a Service (BaaS) White Paper
- Make Sure And Have Multiple KPIs For Your APIs
- API Enabled Toys For Our Children
- I Am Speaking At The Dallas-Forth Worth API Professionals Meetup May 14th
- How Much Do You Spend Attracting and Supporting Freemium API Developers?
- What Does The API Evangelist Do?
- Startups Need To Work Together on API Definitions
- Parse Is Successful By Truly Solving Problems for Mobile Developers