Is it about REST vs WS-* ? No, it's about DIY vs Kits

I'm wondering, am I the last one who has understood this somewhat obvious thing ?

While treading on my code generation path and thinking how would one generate a RESTful
client code properly, I suddenly realized it.

It's not about REST vs WS-*. It's about writing or wiring up all code interfacing the outside world manually vs kits generating it for you. It's about developers skilled and motivated enough, not constrained by various governance rules writing their web services vs developers, quite possibly equally skilled at the least, using the generated code.

It's not about REST vs WS-* at all. Because if one creates a RESTful server by using a generated code with annotations occupying 30% of the actual source then it's hard to see what advantage one can get out of it. Addressability ? How good URIs backed up by a generated code can be ?
Because if one generates a RESTful client then it's not clear how different such a code can be from a typical WS client.

Dealing with WS-* services is mostly about dealing with the code generation. WS-Policy adds an extra dimension to the code generation in that your design-time tool can generate a lot of the boilerplate code by analyzing a given service's requirements presented as WS-Policy expressions. WS-Policy brings some dynamism into the runtime as well but that's off-topic. Writing a WS-* code manually is error-prone. Modern WS-* kits do let developers to plugin their own handlers into the execution path, but kits are mostly in control.

Writing RESTful services such that one can get as much advantages associated with REST as possible is mostly about writing the code yourself. It's not said as a critique here. The thing is, in order to write a service which can truly live up to the promise of REST one needs to take charge, take control. In fact, I'm surprised why so many of us are so thrilled about turning existing Java classes into RESTful services. Developers wishing to write a client code which can survive as many changes on the server as possible would be better off writing as much code of their own as possible.

The more I think about the more I'm getting convinced that arguments like 'RESTful services are better' are really arguments in favor of avoiding the code generation. I do start hearing now people saying that REST does not need WADL or why do you need WS-Policy for REST : they do not deal with generated code, they prefer the freedom of dynamic languages or prefer writing their Java or C# web services code themselves, don't mind writing some code which deals with the security, setting up various handlers.

Does it mean it's wrong promoting RESTful services with the help of WADL or JSR311 ? I don't think so. Many users need to take simple first steps in this respect, only if they appreciate over time that exposing their resources the RESTful way gives their application an edge will they move to the next level. Or they might decide to stay with the generated code if it works for them.

Code-generated RESTful services can be the first step for many developers. Especially for those who are lazy like me :-). What would be the difference then between code-generated RESTful and SOAP clients ? A typical soap client interacts with up to two layers of services : with the service itself and with EPRs returned from that service. Likewise, it's difficult to imagine a generated RESTful client dealing with more than 2 layers (beyond collections and their entry resources for ex). It's not a big deal to write a bit more code on top of it to deal with arbitrary number of nested resources, but perhaps it would make sense in cases like this not to code-generate at all.

WS-* clients get a WS-Policy boost and have client runtimes doing a lot of work for them.
That's why it's easier to see why there's a momentum behind AtomPub in the RESTful community : Atom-powered client libraries will hide some complexity from users, and will help them to address a number of security considerations, etc.

What happens next though ? For example, policies are needed everywhere and there're initiatives in the Atom world for example to address the problem of advertising certain service requirements to potential consumers. How far will the Atom community decide to go ? Will they attempt to try to come up with a policy language which will let Atom collections and entries alike to dynamically advertise their advanced capabilities, something which is possible in the WS-* world ? Or will they decide not to make it more complicated ? Arguably, the advanced capabilities WS-Policy can bring into client runtimes may not be needed for the majority of applications.

It does seem it's not about WS-* vs REST at all. Otherwise, the challenge is how to avoid creating REST-*.

In the end, I'd like to comment briefly on a WADL metamodel published post by Jean-Jacques Dubray as I borrowed a REST-* term from that post. I think once can read a lot of interesting stuff on Jean-Jacques's blog, but I found the conclusion of the post to be a bit emotional :-) :

"Good luck with your enterprise implementation of REST :-)"

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).

As far as as I'm concerned the question is what does it mean to do REST across the enterprise ? Something tells me REST-* may not be the way to do it. But it's a bit too complex to guess it right :-)