REST Interface slide from Cote presentation
Over on his people over process blog, Redmonk Analyst, Michael Cote, has what is a great idea, a rehersal of an upcoming presentation including slides and audio.
The presentation covers what technology is making the jump from the consumer side of applications and IT into the enterprise. I’m delighted to report Cote has used a quote from me on REST.
For clarification, the work we are doing isn’t directly related to our PowerEdge C-servers, or our cloud services. For that, Dell customer Rackspace cloud has some good REST API‘s and is well ahead of us, in fact I read a lot of their documentation while working on our stuff.
On the other hand, I’m adamant that the work we are doing adding a REST-like set of interfaces to our embedded systems management, is not adding REST API’s. Also, since I did contribute requirements and participate in discussions around WS-* back when I was IBM, I’d say that we were trying to solve an entirely different set of problems, and hence now REST is the right answer, to externalize the data needed for a web based UI.
At the same time, we will also continue to offer a complete implementation of WS Management(WSMAN). WSMAN is a valuable tool to externalize the complexity of a server, in order for it to be managed by an external console or control point. Dell provides the Dell Management Console (DMC) which consumes WSMAN and provides one-to-many server management.
The point of the REST interfaces is to provide a simple way to get data needed to display in a Web UI, we don’t see having to expose all the same data, and can use a much more lightweight infrastructure to process it. At the same time, it’s the objective of this project to keep the UI simple for one-to-one management. Customers who want a more complex management platform will be able to use DMC, or exploit the WSMAN availability.
My Linked profile
Adventures in systems land 
Thanks for the extra detail, and the quote 😉
Re:
On the other hand, I’m adamant that the work we are doing adding a REST-like set of interfaces to our embedded systems management, is not adding REST API’s.
Question(s):
Isn’t an API, an interface that is used by an application (and in this case via REST/HTTP)?
Anyhow, am intrigued by the WS-MAN strategy (at Dell). Is it acccurate to say that the DMTF is the Dell strategy and OASIS is not? In my opinion, both bodies are off doing things for the past (with influence by their sponsors, including IBM).
Ultimately, the Rackspace apis (including AWS etc) should converge after the innovation happens (maybe, OCCI). What is missing is the event (state changes within hardware) that should be a push model (as opposed to a pull model).
Thanks for the comment Derik. Historically you are right, Dell was more aligned with the DMTF given both their background and ours, especially given the work and actions of people like Winston Bumpus and my current colleague Jon Haas. They both committed lots of hours to get things done with the DMTF, as did a number of other Dell engineers. So, it’s fair to say thats where we were much more aligned. Dell still has a board member place at the DMTF, currently represented by Jon, and we are active on a number of task force.
It’s too black and white to suggest that it was an either/or for DMTF and Oasis though; and it certainly won’t be like that under my watch, at least in the server space. I am a pragmatic realist when it comes to implementing technology. Personally I’m looking purely for easy to implement win/win technologies for customers and Dell.
As I said in the post, there are some definite advantages to WSMAN, and also to the work IBM did with Oasis on WSDM. However, the data model behind both is very complete and very detailed. They both require a lot of enumeration to get at what should be simple state information, albeit for good reasons. I know Jon has been looking at a number of ways around that within the scope of WSMAN and will hopefully have more to say at a later date.
I agree that what we are doing with REST could ultimately be called an API. However, by insisting that we not call it that upfront, I’m hoping to avoid the pre-disposition people have to jamming all sorts of things into the interfaces that don’t belong there. You are also right that changes to state data in the server need to be managed. Our challenge is three fold, through automation tools that we build, such as Dell RACADM; state can be changed through WSMAN and from hardware state change. To deal with this using REST requires the browser Javascript and the server to use the head data. It looks like doing a Get on the head will show if the data has changed, that provides an efficient pull model; when doing a Put or Post you need to ensure that the backend data hasn’t already changed and if it has take an action appropriate to the circumstance.
Now, what’s missing here is Push. As I said in the post, what we are doing with this set of REST interfaces is to create a means to get/put/post state data in a UI. From that perspective we intend, where needed, to use Javascript in the UI to poll for updates via head. So thats not push, but pretty much accomplishes the same thing. Get the head data, compare to the last head data, either nothings changed or Get since, or Get again.
I’m hoping to be able to publish some details shortly and then even provide an online test system we can give people access to to test against, so we can get changes and feedback as we go. I’m hoping to be able to ship some of this with an update to the PowerEdge 11g servers, but thats not currently plan of record.
Thanks for your questions.