Day of REST approaches for the cloud
It's a style thing
Comment The term REST keeps on popping up when vendors and analysts talk about cloud storage. We're told that RESTful interfaces are more advanced than traditional filer interfaces such as NFS or CIFS. What is REST all about? Let's take a fairly simplistic look at REST, cast an eye in the direction of its advantages over the traditional NAS protocols, and try an overview comparison with Microsoft's SOAP protocol.
REST stands for REpresentational State Transfer and the term was introduced in a University of California at Irvine doctoral thesis by computer scientist Roy Fielding in 2000. The document's abstract states: "REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems."
Fielding has been involved with authoring Internet standards for HTTP and URIs (Uniform resource Indicators) and his work has received a lot of attention.
His paper charts the development of the REST idea from an initial client-server architecture which decouples client systems from servers and enables clients to talk to different servers and evolve separately from them. This interface became stateless in the sense that servers received requests and had no need to be aware of the situation or state behind the request. They just blindly serve it, with no stored context, and leave the responsibility for maintaining state with the client. Servers don't have to store state between requests and can be more efficient with their resources.
Fielding then says we add a visible cache constraint, with data coming from servers being labelled as cacheable or non-cacheable. Cacheable data can be re-used by client systems for subsequent requests by their users or applications, thus avoiding server access latency. Fielding says that this client-cache-stateless-server architecture was that used by the early world-wide web.
He adds a constraint that there must be a uniform interface between components and this becomes a central feature of REST. He states: "Implementations are decoupled from the services they provide, which encourages independent evolvability." This degrades efficiency as information is transferred in a standard form and not in forms suited to individual applications. REST is designed: "to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction."
He goes on to define REST by four interface constraints: "identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." He then adds: "layered system constraints... the layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting."
The benefit of this is that: "Within REST, intermediary components can actively transform the content of messages because the messages are self-descriptive and their semantics are visible to intermediaries."
Finally: "REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts." In summary he says: "REST... gains the separation of concerns of the client-server style without the server scalability problem, allows information hiding through a generic interface to enable encapsulation and evolution of services, and provides for a diverse set of functionality through downloadable feature-engines."
The REST interface style focusses "upon the generic connector interface of resources and representations has enabled intermediate processing, caching, and substitutability of components, which in turn has allowed Web-based applications to scale from 100,000 requests/day in 1994 to 600,000,000 requests/day in 1999."
It has been said that a RESTful access has four verbs for operations and many nouns, one for each resource that can be operated upon via its URI. The verbs are GET (meaning read), POST (meaning create, amend or delete), PUT (meaning create or update) and DELETE (meaning delete of course).
Cloud storage and cloud computing are seen as being gigantic in scale, and REST proponents say that the REST web services architecture is suited to such scaling. They note that storage clouds such as SoftLayer's CloudLayer, Amazon's S3, Nirvanix' SDN and Rackspace's Cloud Files all use a RESTFul architecture.
NFS and CIFS are, simplistically, client-server file data requests whose architecture predated the web. As such they are not suited to cloud storage although legacy NFS/CIFS-using applications can interface to cloud storage through NFS/CIFS protocol access layered onto interface styles such as REST. Nirvanix offers CloudNAS for this purpose.
SOAP and REST
It offers two Web Services APIs though; SOAP and REST. SOAP stands for Simple Object Access Protocol, and was developed by Microsoft in 1998. It uses eXtensible Markup Language (XML) as its message format and various application-level protocols such as RPC (Remote Procedure Call) and HTTP to send messages to servers and get results.
SOAP can be differentiated from REST this way; to use SOAP, developers have to understand the XML spec and will generally need a SOAP toolkit. Every SOAP request and response is wrapped inside an XML coat and this, with associated namespace and data typing information, means SOAP responses can be up to ten times larger than equivalent REST messages. SOAP is therefore heavier weight than REST. SOAP, it is said, is a protocol to use with distributed computing based on XML. REST is not.
We could view REST and SOAP as complementary. SOAP is also, it appears, getting RESTful with a version of its spec admitting the use of URIs be used to expose certain services.
From the storage admin and buying point of view, SOAP and REST are upstream matters. Upstream of the storage array and starting on the server that interfaces them to the ultimate users of those arrays across the Internet cloud. For storage consuming applications that look to get and/or develop cloud storage services then SOAP and REST are highly relevant.
REST is a way of setting up and operating Web Services interactions, not a formal prescription of exactly how you develop them.
Since REST is an architectural style there is no defined REST protocol, no standard REST toolkit, and no defined and standard REST facility which says whether a particular cloud storage interface is fully RESTful or not. It is all, literally, cloudy. ®