REST for developers - it's only a beginning

In my last post I asked Steve Vinoski some questions about REST and WebServices. I'd like to comment on the questions a bit more. First though I'd like to thank Steve for taking my questions the way he did and providing interesting answers , likewise I appreciate the comments made by others.

One thing I'd like to clarify is that I personally do not need to be convinced about the viability of REST or the fact that WEB is going to affect one way or the other the way we do the distributed software. As I mentioned earlier and indeed as obvious from the public efforts of various vendors, REST is being noticed and thought about.

My questions were really a reaction to the very last "no contest" phrase in the Steve's post . I respect the Steve's visionary opinion and by no means it was kind of "how could you say it after all you've done with Corba" reaction. "No contest" may well prove to be much closer to the reality at a wider scale sooner or later , but it just does not work for me yet.

Generally, arguments like "If you do REST your application will scale to millions of requests" or "Look, Google and Yahoo does it" or "it's just simpler" simply do not work for me : it may well point to the serious lack of vision on my behalf :-) , but I find such arguments sometimes being somewhat detached from the reality and this is exactly why I liked RESTful Web Services : while favoring REST it was not very absolutist :-) at the same time.

So to some of the questions. Inspired by the Out Of the Frying Pan post where the first counter-argument is hidden in highlighted comments :-), I wanted to say through my random set of questions that IMHO there's still a lot which needs to be done for REST for it to truly start competing with WebServices, as far as attracting large groups of developers is concerned, as far as writing RESTful applications for more than just browsers and generic Atom readers is concerned.

Questions 1, 2 : Code generation, dealing with the change, large-scale client-side REST programming.
I'm not sure the problem of the generated code being too brittle is specific to Web Services for a start. The only thing which is specific to Web Services is the interaction model built around SOAP. Bill D'Ora in his post "Why To Use Atom" (it seems to have disappeared from Bill's blog :-)) says that one of the main reasons to use Atom is that Atom clients know how to ignore unrecognized extensions. I'd like to say that if you look at an atom:feed and hello:world elements coming from the wire, there's absolutely no difference as far as dealing with unknown extensions in atom:feed and hello:world elements is concerned.
Client runtimes dealing with the generated code have to learn how to optionally ignore unknown extensions. It won't solve all the problems arising from producers changing their services but it will mitigate the problem of dealing with the change. There's already some support in both NET and Java for it to start happening. Better code generation can benefit all types of client consumers but it can help popularize the client-side REST development too and let users to jump to their data of interest straight away. You might say it will trick users into believing WEB is not there, so what ? :-), it's just a start, don't get me started on the code-first development in REST on the server side :-)

WADL : it's strongest feature IMHO is to let to point to the data you want to deal with by using XPath expressions. I wonder, can one use it to deal with all the AtomPub services out there to avoid a need to install a client-side library for every type of AtomPub/GData like protocol ?

3. Is idea of interface is broken ?
I was referring to this comment further commented upon here : "we're not confused at all that a BIG part of the attraction to folks is opaque URIs and no metadata".
Are minimalistic interfaces viable ? I believe so. Coupled with a good extensibilty policy for data pushed through them can make such interfaces a bit friendlier to totally generic interfaces without compromising much the need to deal with changes. Ultimately, a generic interface is understood by all the generic tools but I don't believe that at the moment one can "switch communities" easier with generic interfaces when writing not so generic consumers : GET and friends do not tell you about the semantics.

4. Software modules using generic methods : I was somewhat emotional here, sorry :-) If everyone wants only generic interfaces then why don't we start advocating all the software components using the same generic interface WEB uses and have them relying on various properties passed through call contexts to understand what needs to be done. No need for assemblies, OSGI and for a first class diagram in the Stefan's presentation :-)

5. Is WS-Policy useless ? Dan asks Is Security The Killer Feature of WS-* ? I won't go into this topic :-). But IMHO WS-Policy is a very strong feature indeed . Facilitating the interaction with services which have complex requirements, both at the tooling level (design time) and at runtime is what WS-Policy can bring. That's why either a similar language, or may be even the same language needs to be used for RESTful services for doubts in their ability to deliver complex applications without forcing clients to do sophisticated bootstrapping code are to disappear.

There're more questions, but this post is getting long so I'll comment on one of the last ones :

"What is the difference between service factories found in Corba and RESTful services creating new child resources as part of POST (as far as managing child resources is concerned" ?

I agree, the interface is different. But what I was really trying to say that as far as dealing with transient resources is concerned to which few if any of possible advantages of REST can be applied, I'm not that sure at all that creating a new resource per every POST scales well. You need to delete them explicitly, extra call, what if the client ends up with a stale URI, etc. I think coarse-grained interfaces may have an edge here. Possibly in areas of distributed activities, etc...

That's it so far, thanks to everyone for commenting and reading !