Have you ever wondered why there do not seem to be any new computer and network standards? The Internet would not exist if it were not for TCP, HTTP, and other indispensable standards for network interoperability, so where have they all gone? Standards are still quite alive and well, but they are now considered old school. For the most part, they have been replaced with APIs (application programming interfaces), which offer more flexibility for users and developers, in addition to being faster and easier to implement.
Computer standards have long been the bedrock of what makes our networks, applications, and computer systems what they are today. For years, industrious volunteers with the support of the IEEE, IETF, and other standards bodies, have quietly worked at creating the standards that support these systems. While standards are essential, they are slow to develop, sometimes taking years of delicate negotiations among competing vendors and stakeholders to hammer out the details.
For example, cloud computing, which was inarguable built on Internet standards, has long been subject to a confusing set of conflicting definitions. SaaS (software as a service) and IaaS (infrastructure as a service) are more or less clearly defined to most users now, but beyond that, the many attempts at creating a single cloud reference architecture have only continued to frustrate everyone involved.
What makes APIs different from standards is that APIs are typically developed and published by a single entity, such as a vendor, rather than a standards body. The open source APIs published by the OpenStack Foundation and other similar entities lay somewhere in between.
APIs are designed to make it easy for other entities to integrate their software and systems by having developers interface their software with the API rather than the application internals—if the developer even has access to this proprietary code at all. At their best, APIs are relatively quick to create and maintain.
The vendor merely needs to publish the interface standards, such as what it expects to see returned for a given variable, rather than exposing the details of their application. The advantage to the developer is that the internal code can continue to develop and change and as long as the API variable remains constant, outside users can still integrate with the system.
The appeal of open source is that anyone can contribute to the community and get what they need from the project. To achieve that goal, many open source communities have relied on APIs to provide the magic glue to allow the disparate components to be integrated, while maintaining the integrity of each element. For the development of cloud systems, this is essential.
In conclusion, as the push continues to develop software systems faster and more flexibly, APIs will play a huge role in meetings those requirements. For software vendors that have not developed APIs as they developed their code—the API first approach—it is not too late to speed integration with other applications and systems by developing and publishing APIs now. It is never too late to get on the integration bandwagon.
