How is cloud computing contributing to changes in APIs?
Application programming interfaces (APIs) provide the specifications used by software components to communicate with each other. What makes APIs important in cloud computing is the now wide-spread practice of making these interfaces generally available. This openness is the result of the emergence of cloud computing speeding the evolution of APIs.
APIs have been around for some time. But what has changed with cloud architectures is the design models used, such as REST, which provides a level of consistency across implementations. This consistency speeds adoption by developers and speeds innovation because it makes coding to new platforms easier. APIs provide the access to cloud resources such as compute, network, and storage, which allow innovative developers to build new business applications—and to extend and customize systems.
The evolution of APIs has also introduced some tension between expediency and rigor, though any limitations are seemingly being overcome if the number of available and extensible apps is any indication of broad acceptance. Extensible standards have also helped blur the lines between industry-defined specifications and boundless flexibility.
Levels of Interoperability
A few months ago I published a blog post about the API-Driven Cloud. In this post, I compared and contrasted the need and benefits of both open and industry-standard defined APIs. Interest in the subject was high. Why? I suspect it was the combination of APIs being an important element in cloud computing models, and the fact that someone from a storage vendor was blogging about the subject. Now, in this post, I would like to delve a bit deeper into the area of APIs.
Approaches to APIs vary depending on when and by whom they were developed, and how they get used. While seemingly evolutionary, the different approaches have their place and can be thought about in terms of the levels of interoperability each provides.
These API approaches include:
- Proprietary: These APIs are interfaces designed by vendors and are product-specific, meaning that only that vendors’ product or products supports them. When these products get combined with other products with incompatible APIs, some middleware is necessary to bridge the gap. A whole class of middleware products exists for this purpose (e.g. enterprise application integration solutions from vendors like BEA, Progress Software).
- Protocol-based: Historically, many APIs have been language based like the Java API or .Net API. Then, about a decade ago, SOAP (Simple Object Access Protocol) for exchanging structured information in the implementation of web services emerged. SOAP helped move us away from language-based APIs to protocol-based APIs, more loosely coupling the client and server. The server could be written in Java and a client in PHP, for example. Now, most APIs come in the form of REST-based interfaces over HTTP and are a great fit with cloud computing because they are based on web architecture. Note that moving to REST alone does not mean that the interface is standardized; it may still be proprietary, requiring middleware for interoperability. But, with HTTP-based RESTful services, APIs offer developers a degree of consistency.
- Internal or de facto standards: When multiple parties begin to support a common interface, this lessens, but may not entirely eliminate, the need for middleware. The multiple parties could be various groups within a company, such as what was done within EMC to create the EMC Data Access API (EDAA), now included in EMC ProSphere, EMC AppSync, and EMC Data Protection Advisor software manageability products. The multiple parties could also be across different companies. Occasionally, this collaboration can result in a non-formal standardized interface becoming a de facto standard (e.g. Amazon Simple Storage Service (S3)).
- Industry standards: While propriety and de facto standard APIs have their place, so do industry-standard APIs. When multiple companies work collaboratively, under the umbrella of a standards organization (e.g. W3C, IETF, JCP, SNIA), the details of an interface are formally documented and then implemented by multiple vendors. This approach can and usually does take a long time, because of the many different perspectives involved and the need to build consensus. But, there is no question that there is significant value in formal standards. The Web—and cloud computing—would not be possible without formal standards around media types (HTML), identifiers (URLs), and protocol (HTTP), for example.
Finding the Sweet Spot
In an ideal world, it would be great to minimize tension between the expediency afforded by protocol-based standards, and the rigor provided by industry-standard APIs with some sort of compromise. This sweet spot might actually exist in the form of an extensible standard. This ideal includes a foundational specification plus extensions that enable customization on top of a strong footing.
The Atom family of specifications is one example of an extensible standard. The Atom Syndication Format (RFC 4287) arose out of the need to resolve different versions of rich site summary (RSS)—also sometimes called real simple syndication. This foundational specification which provides a model for representing entities and sets of entities has many extensions. Originally focused on blog posts, Atom has since been used as the basis of many other programmatic interfaces, including EMC’s EDAA. Extensibility is made possible because XML elements can be included that are not part of the original specification. The original specification explicitly allows for this extensibility and states that a client that does not understand this foreign-markup should simply ignore it. This is a very powerful extension point!
Subsequent to the initial specification, the Atom Publishing Protocol (RFC 5023) added actions for creating, updating, and deleting entities. It also added elements that the original Atom Syndication Format would consider foreign markup, and extends the entity/set model with special types of sets called collections, as well as a description entity. Other specifications that extend the initial format include Feed Paging and Archiving (RFC 5005), Threading Extension (RFC 4685) , and License Extension (RFC 4946). Note that extensions to an extensible standard API can be proprietary such as with EMC’s internal (EDAA), a de facto standard, or fully standardized. Extensible standard APIs may be harder to produce than other types of APIs, but they are worth it. Think: the best of both worlds!
Out in the Open
Why should you care?
If you are a developer, application owner, services provider/entrepreneur, programmable interfaces open up systems and applications to third-party adoption which is important in the rough and tumble world of cloud computing.
Case in point: MySpace compared to Facebook. MySpace is an application with a set format. Facebook is an extensible platform. We all know who prevailed.
Thank you to Cornelia Davis for sharing her knowledge about APIs for this post. Cornelia is a senior technologist in the office of the Chief Strategy Officer at EMC Corporation. As a member of the architecture group, her primary focus is on integration approaches with an emphasis on RESTful SOA.