·:[ Integrate This ]:·
• • • • •

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.