We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Leveraging Information and Intelligence

David Linthicum

Why Web API Directories Drive Data-as-a-Service

Vote 0 Votes

The emerging number of Web APIs out there, and how to leverage them for mashups or other applications as data-as-a-service resources. This is the most exciting and interesting area of the emerging Web right now, and the more you understand what's coming, the better you can take advantage.

Keep in mind that the core value of Web APIs are their ability to produce and/or consume information or functional behavior, machine to machine, server to mashups, or server to any Internet-connected application. Thus, you can mix and match information and behavior from any number of sources to form a business solution. Some of these sources you own, perhaps some you don't. These are typically non-visual services, and the interaction is happening behind the scenes. The power of this concept is the fact you don't own nor host these services; many are free and or at low cost to you. Thus, the value proposition is speed, agility, and efficiencies.

So, how do you find the thousand of APIs out there scattered among hundreds of API providers? Just as we needed a mechanism to find Web content back in the 90s and search engines appeared, new directories are appearing, and will continue to appear, allowing you to find the right API. Early leaders include the Programmable Web API directory, with hundreds of APIs already listed, and more added each week.

What's cool about this is that human-readable directories won't be the direction here, but instead shared repositories of APIs/services. In other words, the ability to link to a shared database that contains information about thousands of available APIs/services, and have that repository be part of your existing private service repository. Thus, you have a private repository of services you own exclusively, or are private, and also include APIs/services that are public.

Considering this within the context of the emerging notion of SOA, you're able to break your existing systems down to a collection of services that can be leveraged within business processes to create business solutions. Along with those services, you can also add thousands of public APIs/services for things such as demographics data, mapping, social networking, messaging, etc., and be able to mix and match these APIs/services, private or public, to create some killer business solutions. This is the emerging concept behind the enterprise mashup.

The critical success factor here is the ability to go from a state where the APIs are widely scattered, deployed differently, and are difficult to find, to a shared infrastructure where the APIs/services can actually be discovered and leveraged as if they were local. In many instances I suspect they will be even more reliable than their local, private counterparts when considering that there will typically be more investment in the infrastructure around public APIs/services than services that are intra-enterprise.

While we are waiting for a common directory/repository, or while we're awaiting the existing directory/repositories to refine them, it's still a good exercise to learn how to leverage external APIs/services within your core business applications, even if it's just as a proof of concept. The fact of the matter is that our ability to find and leverage the right APIs/services quickly, and leverage those services within your core business processes could be the secret sauce that allows you to out-innovate your competition.



MuleSoft recently launched the open source project iBeans to help make accessing Data-as-a-Service from web applications much easier. Mule iBeans is an integration framework that allows your existing web applications to interact with other webapps and services. Individual iBeans are interfaces that specify how to interact with a remote service or API. The most exciting part is that, with iBeans, MuleSoft is hosting iBeans Central, a public repository of community-contributed integration beans.

So, for example, if you create an iBean to access your demographics data service, another developer could pull that iBean down from iBeans Central and use it to easily access that service from their web application. This greatly simplifies the exercise of learning how to leverage those external APIs/services within your core business applications.

iBeans is still in it's early days, but is based off of years of development on the open source Mule ESB. It is my hope that it could ultimately fulfill the vision you describe of an easily accessible public repository of data services.

Hi David,

Just to follow up on Ken's comments, I did a screen cast that provides an overview of iBeans (the intro is 3 mins, the rest is looking at the code): http://vimeo.com/7413382

Industry expert Dave Linthicum tells you what you need to know about building efficiency into the information management infrastructure

David Linthicum

David Linthicum is the CTO of Blue Mountain Labs, and an internationally known distributed computing and application integration expert. View more


 Subscribe in a reader

Recently Commented On



Monthly Archives