The best way to find REST in Storage Management is to know what has existed previously in order to fully embrace what REST can do for you.
Communication via object brokering and web services has been around a long time. The temptation in using these technologies for Storage Management is great since we “engineers” are pretty “geeky” and these technologies are pretty “geeky”. Having this mindset when it comes to Storage Management causes lots of meetings (and the possibility of job security), but in the end, the customer is at the mercy of these ideas which eventually become very thick standards, years of engineering change orders, slow network transfers due to multiple class traversal, etc.
If we take a step back to see what we’re really trying to accomplish, we may find REST in our Storage Management future.
SOAP versus REST
From a historical perspective, SOAP, formally known as Simple Object Access Protocol, is an object broker-based enveloping scheme layered on top of HTTP. It was thought that we could move away from the more RPC-like instantiations of object brokering and use HTTP as the transport layer for the objects. It was thought that HTTP alone was not powerful enough.
But SOAP doesn’t scale very well and requires both sides to agree to a service contract based on proprietary APIs and object schemas. The list of APIs can grow into the hundreds. Discovery in this model is painful and if either side of the service contract changed, it would break the other side, so tight synchronization was required. Responses to commands can vary and thus can get out of sync as well.
REST, Representational State Transfer, on the other hand is purely HTTP with the HTTP Method and Response sets acting upon “resources”. Since REST, as an architectural style, is purely an HTTP layer play, then using REST scales to the internet since HTTP scales to the internet. This means within a particular customers’ networking infrastructure, the customer can scale to the size of their intranet.
And since REST is “resource oriented”, every resource has its own unique address (URI) within the scale of the network making discovery a snap. The “API set” in HTTP is just the main 8 methods, of which, 4 are used most of the time: GET (Retrieve), POST (Create), PUT (Update/Modify), DELETE. This means no service contract is required and any web-based client will “know” how to execute these methods. The HTTP Response set is just as simple with 2xx for Success; 3xx for Redirect; 4xx for Client-side Errors; and 5xx for Server-side Errors. Any and every kind of response can be represented by these HTTP Response codes.
Truly RESTful Web Clients need only a few pieces of information in order to get the job done. This means service contracts are no longer required and the object schemas become optional instead of mandatory. This also means RESTful Web Clients can determine what it’s managing on the fly independent of the server-side version level as long as the server-side “tells” the client how to get around by using “hyperlinks” within the response body as the Web Client traverses the links. In order to implement a “resource-oriented” system, the system resources must be addressable, stateless, linkable, and have a uniform interface (HTTP Methods).
X-IO REST equals CorteX
At X-IO, we developed and integrated RESTful Web Services into our ISE (Intelligent Storage Element) device in order to make the Storage Management experience as simple as possible. Our marketing name for this is “CorteX”. This means every ISE unit operates as a web site with the internal components represented as resources of the web site. Discovering ISE is as simple as scanning for an IP Address with the GET /query resource to find a response and then determine if the device is an ISE in one call. The /query response contains the “next link” to get further into the ISE (very RESTful concept) in order to continue navigating into the ISE storage management layer. This means any component of the ISE, such as the Power Supply, Storage Volume, Storage Pool, etc., have their own unique address or URI that the HTTP Methods (GET, POST, PUT, DELETE, HEAD, and OPTIONS) can be used against. We chose to use the DMTF CIM Model for representing certain “elements” within the ISE in order to have a base industry-standard attribute set for each of the resources (elements). We extended the attribute set where applicable just as the DMTF CIM specification allows.
REST requires that actions only come from the HTTP methods (verbs) and that the objects of the actions are resources (nouns) represented by fully qualified URIs.
An example of the URI (Universal Resource Identifier) pattern:
domain is the IP Address or DNS Name of the “web site”
offering is the kind of management offering (storage, network, compute)
type is the kind of device (array, switch, server)
id is the globally or locally unique identifier that represents the instance of a type
If “id” is not present, then the system will return a “list of type” instead of just the one type instance.
You too can find REST
So in conclusion, seek out the storage, computer, network, and application vendors that have embraced RESTful Web Services as a means to do management of their devices, applications, and services. And if you cannot find those that have it, demand it from your favorite vendors so that they will finally get some REST too.