My last post on REST generated some attention. Since it is an important topic, I wanted to share some additional links for those who are trying to improve their understanding of REST:
– Dare Obasanjo’s Explaining REST to Damien Katz
– Paul Precod’s Second Generation Web Services, REST and the Real World, SOAP, REST and Interoperability
– More stuff from Roger Costello
– Ryan Tomayko’s How I Explained REST to My Wife
– Roy T. Fielding’s Dissertation: Chapter 5
REST reflects the architecture of the Web. One of its most important characteristics (and there are many) is that it is “stateless”. That means that a REST style command from a requestor to a responder has everything in it the responder needs to know in order to take an action. No further handshaking is required. Very efficient and Web like. Since it is “stateless” it works very well with a “stateless” server architecture, in order to achieve Web scale. In this way many clients can interact with many servers against a large pool of objects to accomplish many interactions, well, you get the point, Web scale. That’s one reason we use RESTful Web Services API commands to access the Mezeo Cloud Storage Platform servers, which are also stateless architectures, implemented via Linux. Web scale, one of the requirements of cloud.
REST is also highly efficient, so that interactions between requestors and responders via a network can be done with a minimum of overhead. If you ever download a 500 gigabyte file via a cable modem based internet connection, you will likely appreciate any efficiency that can be achieved. Speaking of efficiency, REST also accommodates caching, at both the client and the server, which can dramatically improve the efficiency of your interactions with the “object” (an object could be, for example, a file, like a picture, or a pdf).
Developers who utilize RESTful Web Services APIs to create applications appreciate the efficiency and capability of the APIs. Expect, over time, to see more commonality among base case APIs and other APIs that expose storage cloud specific advanced services. For example, Mezeo based clouds offer a secure share, collaboration, notifications, and nested files and folders, for example. Some clouds may have such a unique set of APIs that others will create translators (wrappers, for the IT guys in the audience) for them, and we will continue to make headway on openness.
RESTful APIs are a critical part of new application development, and represent the delivery of Service Oriented Architecture infrastructure for storage. Storage is now programmable. And I bet you thought cloud storage was just a utility computing model applied to storage, for scalability and pay for use. Both are necessary, but not sufficient for cloud storage.
Most of us in the Cloud Storage industry strongly believe that a key capability of a storage cloud is the REST style Web Services API. Many of the most popular storage cloud services include or exclusively use REST, including SoftLayer’s CloudLayer, Amazon S3, Nirvanix SDN and Rackspace Cloud Files.
Other access methods that are most often associated with Cloud Storage access include cifs, NFS and WebDAV, NFS and cifs are not particularly usable via an Internet connection and therefore useless in public cloud offerings. While WebDAV is very useful for an Internet connection, it is similarly limited, in that all three protocols support traditional file operations like store and retrieve, versus the robust set of services that Web Services APIs can deliver.
Amazon introduced S3 with REST style API access only. Cloud Files from Rackspace also utilizes REST style APIs. Nirvanix SDN utilizes both REST and SOAP APIs. Mezeo offers REST APIs. Various groups are also engaging on the issue of what representations of REST should be common across cloud offerings. The SNIA, (the Storage Networking Industry Association) has assembled a technical Cloud Storage working group for further refinement of REST style implementations for several purposes.
So, what is the purpose of the other, older access protocols? When deployed with API based Cloud Storage offerings, they provide additional options for legacy applications to expose their objects (files) to the advanced services of the Cloud, and further make these files available to the new API based applications.
Why all the excitement about RESTful APIs? Cloud Storage is more than a utility business model applied to traditional storage. It is storage that is accessed via Web Services APIs, over a network. Developers utilize these APIs because they are easy to use and they expose significant capabilities and services from the storage cloud, far beyond scalability, performance and pay for use. As I have said before, scalability and pay for use are as much a business decision about how you sell storage, as they are a technology implementation of storage. If there were no need for the API based services, the older and well used protocols would persevere. This is clearly not the case.
I have carefully avoided the use of the word “standard” associated with the REST style or architecture. Here is an interesting view on that topic from Roger Costello:
REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer’s toolkit. Why? Because REST is just an architectural style. You can’t bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)
Cloud storage service providers understand that a new storage infrastructure has emerged, as an embodiment of Service Oriented Architecture, with a set of services that are delivered via APIs. Scalability, performance and pay for use are attributes of traditional and cloud storage solutions, but Web services APIs are the distinguishing feature of cloud storage. Accessing storage via Web services APIs represents a revolutionary change in storage, not a simple generational change. REST APIs are the embodiment of the way the Web works and are necessary to expose storage as a “storage cloud”!
What should you expect in relation to these API issues?
Most of us expect that over time, there will be a base set of specifications that are jointly developed within the marketplace and by various industry organization, resulting in a well accepted set of representations for REST style Web Services APIs. At a panel at Hosting Con earlier this week, both Emil Seyegh of Rackspace and myself confirmed that when the industry gets further clarity on this specification, it will be relatively easy to introduce those APIs into our offerings, and that they can co exist with our current APIs.
REST is a topic that you will continue hearing more about. You’ll most certainly hear more about it from me in future posts.