Welcome to the API economy. Heralded by both technology departments and C-Suite professionals, APIs have shown to deliver increased revenue streams and bottom-line savings. APIs are the way that software is connected, and in our culture of sharing and integrating, it seems like it’s all that we want to do. And why shouldn’t we? Social media, cloud computing, mobile, and analytics have transformed the technology and data landscape and connecting all of it seems like the logical next step. A survey conducted by the Cutter Consortium and Wipro showed that the business side of organizations wants to build API programs, “to develop new partnerships, increase revenue, exploit new business models, improve time to market, and develop new distribution channels. Meanwhile, technology departments want “to improve application integration, mobile integration, and support the connection to more devices.” APIs seem like a win-win for the entire organization provided that everyone understands the strategy and works toward common goals. But before your organization jumps head first into APIs, it’s important to understand the basics of what an API-based web application architecture is and how it works.
An API is an interface that allows one program to interact with another. It is a set of commands that a program or software application provide that, when submitted to that application, instruct it to do something or alter the way it does something. The important thing to remember is that these aren’t commands in the sense of mouse clicks or typed instructions, but rather they are meant to be submitted by other applications, also known as clients. This permits a few related but distinct features for an application. First, each application is concerned with its own business as it doesn’t need to do everything. Its authors don’t need to conceive of every possible use of the data it stores or the features it provides. Second, to anything outside an application it’s a black box and how it goes about its business is not a concern externally. It doesn’t matter what language it’s programmed in or what specific kind of database it uses. And, of course, the same thing is true of the application using the API. Third, and most importantly, interaction with and use of the API and therefore of the underlying application, can itself be programmed. It can be automated. Data retrieved from it can be acted on by other applications for other purposes. Entirely new applications can be written around it, with their own processes and interfaces.
There are a number of different kinds of APIs. A programming framework is an API. At heart, a content management system such as Drupal is basically an API. It provides a lot of functions that do complex things, such as displaying forms and accessing a database which a programmer can employ to provide interaction for a web user. But what most people mean when they use the term “API” is specifically a REST API which is a set of URLs provided by a website which, when requested, usually cause an underlying application to act on data in some way. That these are URLs adds a fourth feature to an application; it doesn’t have to run on the same machine as the client. It doesn’t even have to be in the same environment, network, or in any kind of proximity whatsoever. It’s on the Internet, and anyone can program to interact with it from anywhere else on the Internet. This transforms the application from a standalone program that has to be downloaded, installed, and run into a service. The application is now the seed of an ecosystem—a modular, distributed network of programs that interface with the core application, each providing its own style or means of user interaction; each performing its own particular functions with the data flowing into and out of the service; and each in effect extending the application itself though still within the constraints dictated by what capabilities its API exposes.
Finally, since the API is an interface, and not the actual application itself, changes can be made to the application without breaking the operation of the clients interacting with it. As long as the API remains consistent—as long as visiting a particular URL with the proper credentials in hand can be trusted to produce known results—the internals of the application can be altered even to the point of changing the programming language with which it’s developed. The canonical example of all this is Twitter. Twitter itself is a fairly straightforward application. It stores text data, sorted by date and organized by association with its authors. But Twitter exposes an API which allows you to access, not only methods to read and write those posts, but to access the metadata associated with them (information about the data, such as dates and flags, etc.). This allows a programmer to develop all kinds of ways of examining the social network it represents and ways which Twitter itself may have no interest in developing.
The population of people who can come up with things to do with the data and features is now as large as the population of programmers who care to interact with the API. The core application itself now doesn’t have to perform every conceivable function, but only do one thing well, and provide carefully designed access to that one thing. And any component of the ecosystem can be swapped out or upgraded without interfering with the functioning and utility of the whole.
As you can see, this all makes for a very powerful way of doing things. So if your organization wants to put APIs to work and reap the benefits such as storing large amounts of consumer behavior data, predicting consumer behavior, and building an audience through networks, then this may be the way to go. The result of a well-planned and highly-focused program will, at the same time, reduce your costs and add tremendous value to your organization.
Please contact us if you are interested in working with a high performing development team on a web development project where APIs are integral and one requiring our digital strategists, web designers, web developers, and data integration engineers