It’s what you don’t see about the emerging Web that has everyone excited these days. Namely, it’s the powerful application programming interfaces, or APIs. APIs are nothing new and have been traditionally cryptic and difficult to use. However, the advent of Web services along with the notion of mashups has changed the way we consider and leverage APIs going forward.

What changed? In short, the emergence of API consumers, including service-oriented architecture (SOA), browsers that support rich client features such as AJAX, and the notion and popularity of mashups.

SOA is having an impact since architectures are moving to both consume and produce services, and these services are able to extend well beyond the firewalls using the appropriate platform services. Thus, partners and customers are able to take advantage of both systems behavior and data now locked up within legacy enterprise systems. In turn, these enterprises can now speak to Web services, consume information and behaviors from other remote systems (such as SaaS, partner applications or Web services providers), and do so without a significant change in infrastructure.

The emergence of Web-based applications that look and feel like native applications are driving the API movement as well. With approaches such as AJAX, browser-based applications are now dynamic and able to interact with users analogous to native applications. Typically these applications leverage a client/server type of a model, where the front end dynamically interacts with the user, and then communicates with a back end. The back end typically contains sets of APIs that provide information in the context of structure, as well as functional application behavior. Thus the emergence of Rich Internet Applications (RIA) drives the need for many emerging API services, and also provides the common platform for mashups (discussed next).

Although mashups use RIA approaches such as AJAX, mashups are really in a category by themselves. The notion has been described to death so we won’t dwell on it here, but for our purposes we can consider mashups as quickly built composite applications that combine information and behaviors (services really) from two or more service providers. These services can be anything from data services, which are non-visual, to visual services, such as mapping and office automation systems. The notion is to combine many things, using standard and well-defined APIs, to create something quickly that’s both new and useful.

How does one create and leverage APIs? There is an art to the creation of APIs for both private and public consumption. When looking to externalize an API you have to consider the current interfaces around the system you’re looking to externalize. In many instances these are existing legacy APIs, information access points, or middleware that already communicates with the existing system. From there you define the design patterns of the existing interfaces, and the design patterns of the APIs you wish to expose. Then it’s time to bring both together into a set of common and final design patterns around the API.

Moreover, you must also consider the importance of normalization of APIs as a feature of an API platform. This allows you to reduce consumption complexity. Without normalization, differently implemented API integrations can add a whole new layer of integration complexity, even defeating some of the purpose.

Building the APIs for private or public use requires an API platform service, an on-demand service that can manage the externalization of that API on your behalf. These services are able to monitor the interaction with the existing system interfaces and map those interfaces into something that’s consumable by other systems, known and unknown, over the Internet. Moreover, these API platform providers should also provide user management services, security, exception management and monitoring, performance management and monitoring, and fault tolerant capabilities…in essence, managing the system interaction from the source (the existing system(s)) to the end consumer of the service/API.

The new Web is all about how systems communicate with systems, applications with applications, and interfaces with interfaces. Where the traditional Web was about content and information as exposed to humans, the new Web will include core business systems as well, which is even more exciting. We’re quickly moving into an age where all information systems will have access to any information required, on-demand, in near real-time. You can only imagine the possibilities.