Clarification for Jean-Jacques

I wanted to comment on some of the Jean-Jacques Dubray's WS-vs-REST posts for a while, in fact I briefly touched on one of his posts earlier.

After looking at my blog reader's listing this morning I spotted a [SOA] Answer for Sergey post. Or no, I've already had all the answers for the questions I asked earlier :-). Either way, how could I miss this post which was done 2 weeks ago ? I can tell you why : as soon as I see a [SOA] or [REST] prefix, my mental filter tells me just to move on to the next post because I already know what those posts are about : they're about the dark side of REST.

I personally see the value in WS-* but I found that after reading Jean-Jacques's posts I start thinking even more about REST. Not sure why. Probably because these posts remind me about pointless WS-vs-REST debates I read 5-6 years ago. Or may be because people naturally react to somewhat strong opinions : it's the same way I react to people saying REST is just the only way to go.

In this concrete post Jean-Jacques comments on one of my previous posts, where I say :

I don't think it's going to stop people from actually doing REST across the enterprise. I believe one can do. After all, RESTful approach is Turing-complete (I don't remember what exactly does it mean :-) but in this context it means one can do any type of enterprise service with REST).

With all my respect to Jean-Jacques's expertise, I have to say he just missed the point
of the post.

And the point was : if you do a code-generated REST all the way then the next step is to do REST-* for the kind of things one can do with some advanced WS-* specs, thus a do-it-yourself approach can be a reasonable and powerful alternative.

As I said, claiming that it's only with WS-* that one can do some advanced things is equivalent to ignoring the fact that REST is pushing WS-* all the way. Different sorts of issues are needed to be discussed IMHO, like will you really get any of REST benefits if you roll out your own transaction system, what's next after you code-generate your RESTful clients and services, how suitable a fine-grained approach for dealing with resources is for different type of scenarios, etc, etc.

Saying that REST creates strong coupling is not very convincing. Big-Bang versioning approach which indeed can quickly help to see if clients are affected does not seem to be the best thing to follow all the time.