Attend any Web API presentation and you are likely to see a graph like this one, demonstrating the growth of publicly-available Web APIs. Speakers (including me) love using these graphs for good reason: they succinctly capture the explosive growth of APIs that has taken place over the last two years.
It’s a great story but it’s really only half the story. Web API experts regularly acknowledge the existence of a “private” or “closed” API market. In fact, many of us believe that if the number of private APIs in use could be cataloged it would dwarf the 7,000 or so APIs that are published on the ProgrammableWeb site.
As with many of the terms in the API world, there isn’t a concrete definition of “private API”. In general, a private API has these characteristics:
- It provides a language-independent interface that is made available via Web protocols.
- It’s access is limited to a specific set of known developers or organizations.
- It is not marketed to the general public nor is its documentation made publicly available.
Further to this, we can divide private APIs into three major buckets:
- Internal APIs that exist within the organization’s borders (for example, SOAP-based interfaces within an internal Service Oriented Architecture).
- Business-to-business (B2B) APIs that enable organizations to integrate with external companies.
- Backend APIs that drive mobile, Web and device-based applications.
With this definition we can see that there are a great many integrations that must already exist. Enterprises have been building SOAP and B2B-based connectivity for years and have accumulated healthy inventories of private APIs.
In addition, the headlong rush towards the world of mobile is driving the creation of new externally-facing APIs to help corporations reach their customers. As I’ve talked about before, many organizations wish to retain control over the development of these applications and they can do this with private APIs.
If IT teams have been building these types of in-house connectivity solutions for so many years, there shouldn’t be much room left for innovation or improvement, right?
Not quite. Unlike those who build private APIs, public API designers are motivated by the need for their interfaces to be chosen out of the mass of APIs that are available to their prospective users. This difference in motivation has created a massive impact on how public APIs are designed and managed. Architects responsible for private APIs have a great opportunity to learn from the public API world by adopting design strategies devised to drive adoption, in a controlled manner.
A good reason to take a developer-centered approach to private API design is the development cost associated with building applications that utilize the interface. A well-designed private API can reduce the project costs for application development as well as for maintenance and upkeep of the integration. Good design isn’t easy but it pays off – even when the audience is limited.
Many enterprises are implementing a “private for now and public later” API strategy. It is a great idea but that doesn’t mean architects shouldn’t strive to incorporate great API design and a solid management solution.
In my next post, I’ll dive into private APIs in more detail and talk about some of the specific challenges that arise when building closed interfaces and how these challenges can be addressed with management solutions.