Ian Foster on state and REST
Ian Foster, well known Grid Illuminati, wrote an interesting draft paper titled
“How do I access state? Let me count the ways” (Google’s cached HTML version) earlier this year (which somehow evaded by radar), that discusses various approaches to handling state in four alternative architectural styles (or parts thereof) vying to be the base style to make the big picture Grid/SOA visions a reality.
It’s an interesting paper, with a fairly solid introduction to the issue that I agree with almost entirely. It’s also flattering (for the whole REST community, not just myself) that REST is even considered. Unfortunately, the conclusions fall short of the high standard set by the introduction, as REST is misrepresented.
The first indication of problems is the title of the first concluding sub-section; “Implementation Architecture as a Nonissue”. Prima facie this seems questionable, as the study of software architecture tells us that the architectural style one choices is critical in determining the resulting properties of a system. But let’s dig a little deeper;
It has been argued that some interfaces permit more reliable or efficient implementations than others. However, this argument is discredited by the fact that the messages transmitted across the wire in each approach contain essentially the same information.
The emphasis on “essentially” is mine, because the fact is that the messages described earlier in the paper do contain different information, and, as it turns out in this case, that information is critical to fully appreciating REST (and other document oriented architectural styles, though the paper doesn’t get into any of those).
Though there are several claims in the paper that misrepresent various aspects of REST, as well as confusing the Web, REST, and common practice using both, the following from the summary is probably the single most significant misrepresentation, and I’d guess the cause of the belief that lead to the problem described in the previous paragraph. It reads;
In contrast, what we call the State Id and REST approaches adopts a domain-specific encoding of operations, on top of SOAP and HTTP, respectively.
In a RESTful use of HTTP, HTTP provides the operations; there is nothing more to be encoded, domain-specifically or not. Only the data payload – the document representing the state of the job, or whatever it might be – is required, as I previously explained . It’s an odd oversight, because Table 6, which details the RESTful messages, makes no mention of any operation other than the HTTP ones.
I’d be interested in Ian’s comments about how this might impact the paper’s conclusions. I’d also be happy to provide a more detailed response to some of the other claims about the REST approach that I disagreed with, if requested.
Hi Mark – I provided some of the stuff on REST to Ian through comments I made on a Grid mailing list (advocating/advertising REST to the Grid community), Ian put some the comments into the paper but a lot of things are incorrect as you point out, the paper is essentially a draft (which is why you found it in a Google cache). Savas currently has the pen on the paper – he said he would correct the REST errors but no progress has been made in a while.
I am not a REST expert – but I have advocated it to the Grid community because no one else would…
cheers
Comment by Mark Mc Keown — September 9, 2005 @ 11:17 amMark
Thanks for finding this post, Mark. It’s good to hear Savas is on the job.. though I hear he’s distracted with another job at the moment. 8-) I look forward to seeing a revision, whenever that happens.
Thanks for your efforts in promoting REST too!
Comment by Mark Baker — September 9, 2005 @ 11:58 amHey MarkB,
As MarkMcK has pointed out, I have the pen on the paper. Ian asked me to co-author it because of the many corrections (mostly on REST) I sent him. Mark is also a co-author. I have been really busy with the move but I was planning to send a first draft tomorrow around to the co-authors :-) I just can’t believe your timing. As if you knew :-)
.savas.
Comment by Savas Parastatidis — September 10, 2005 @ 11:39 pm