(Hopefully) Constructive Feedback on Mark Baker's Article

Update: Mark Mark responded; I’ll try to comment ASAP.

I have to admit that the last post about Mark Baker’s article was a bit harsh — and definitely did not contain much constructive criticism. So I probably deserved the comment I got from Mark. Let me try to go into more detail about the problems I have with what Mark has written:

As a proponent of using the REST architectural style for Web services development, I’ve often been frustrated when I hear REST dismissed out of hand as a solution for some problems, while at the same time, “document style Web services” are deemed amply suitable for it. This frustration stems from my view of REST as a generalization - an “uber architecture” of sorts - of coarse grained, loosely coupled, document oriented approaches to application integration, which suggests to me that anything that can be accomplished with document style Web services, can be accomplished within the constraints of REST, and in a not too dissimilar way either.

Up to this point, I totally agree. I don’t claim to be an expert in REST in any respect, but from what I have gathered about it so far, it definitely seems that the ideas behind REST are applicable for a lot of scenarios.

In this essay, I’ll describe how core features of the Web relate to document style services, and in doing so, will describe how to build the Web with Web services.

Wow! This is going to be a great article — finally somebody who gets both REST and whatever-you-want-to-call-non-RESTual-services, is going to explain the differences and similarities! I’m thrilled.

What a document isn’t, at least by the (IMO, accurate) use of the term in a Web services context, is a bag-o-bits which isn’t asking anything of anyone; the current time, a purchase order, a signup sheet for pickup floor hockey.

Er … well, I think I can see the point, but I can’t really make sense of the examples. So, a purchase order isn’t asking anything from anyone? That can’t be true — so obviously, these are counter examples - a purchase order is asking something. Looking at the paragraph, even for some length of time, I have problems finding out what exactly Mark is getting at - I fail to see the similarity between a pure piece of data like current time and a very concrete, business level document like purchase order. Arguably, it’s just not phrased very clearly, or maybe it’s because I’m not a native English speaker.

They aren’t asking anything of anyone, because their job is simply to capture state; a signup sheet captures the state of those who desire to play, a purchase order captures the state of the desire of a purchaser to acquire some goods or service, and the time, well, communicates the state of some clock.

Now I’m totally lost. (Again, probably my English.) A purchase order isn’t asking anything of anyone, if just captures the desire of a purchase to acquire some goods or service? When I write a purchase order, I clearly ask the supplier to deliver some sort of goods to me. How can this not be asking for something?

Documents are state.

OK, I’ll buy that and move on, there’s surely going to be some more detailed explanation about this later, right?

When dealing in documents/state, a designer often finds it useful to be able to know which documents are about the same thing. For example given two documents representing the state of some business process, it’s quite useful - and often necessary - to be able to determine if the two documents are both of the same business process even though they differ due to, perhaps, being snapshots taken at different times.

Although I don’t consider “quite useful and often necessary” to be enough of an explanation, I agree, so let’s move on:

There is more than one way to address this problem, of course. One way would be to include information in the document which could be used to uniquely identify the business process; the parties involved, the time it began, etc.. While this has its advantages, it also has two large disadvantages; the inability to support alternate formats (e.g. images) which can be used to represent the state of the same business process, and that those identifying characteristics are known only to software which also knows the format. That latter problem would prevent, for example, a generic caching mechanism.

I almost wrote another “I agree” below this quote, but then I thought a bit about it. While Mark obviously was thinking of content negotiation, support for Expired headers and so on, he doesn’t talk about it at all. How is anybody supposed to make sense of that?

I’m also left with the question of what, exactly, the advantages of the first approach are (“… has its advantages …”).

I’m fine with the transfer/transport distinction. But then Mark goes on:

And of course, what one could achieve with the “PROCESS-THIS” (aka POST) and “STORE-THIS” (aka PUT) operations would require that the protocol that defined these operations be used. They wouldn’t be “protocol independent”.

So what? Is this an advantage? Or a disadvantage? How am I suppose to make sense of this remark, unless I have previously made up my mind on the question of REST/HTTP vs. SOAP/anything?

In the next paragraph, the point seems to be that GETting documents from somewhere might be useful too. I just have to agree.

OK, I’m a bit puzzled by now, but surely things are going to be clarified in the next few sections. (Seriously, that’s what I thought when I first read the article). Imagine my surprise when I saw that the next paragraph’s title is Conclusions:

The relatively recent shift away from RPC and towards “document exchange” (aka state transfer) is extremely welcome progress for this POV, but IMO, just the first step of many towards fully appreciating the enormity of the World Wide Web project.

In a conclusion, it makes sense to combine some of the preceding text’s contents and present them in the form of a summary. Now where was the “recent move away from RPC and towards document exchange” mentioned before? Who made this move?

So here’s is my conclusion: Maybe Mark is so smart that he just can’t explain things that he considers to be obvious to everybody. (Maybe the article was, as he explained, really written for people he has already exchanged opinions with for hours.) So perhaps Mark really has a lot to say, and I just fail to understand it. Then again, perhaps not.