Joe Gregorio answered some questions about WADL in his post "Do we need WADL?". Also note that Leonard Richardson has chimed in recently on the WADL issue. And I of course have some different thoughts. :-)
Quotes from Joe in bold italic, mine in plain.
If I describe an Atom Syndication Feed in WADL, how close will the generated code be to a feed reader like Bloglines? Or even to a library like Abdera? If I write a really good WADL for (X)HTML how close will the generated code be to a web browser? The point is that generated code stubs are so far from a completed consumer of a web service that the utility seems questionable.
I don't think anyone is expecting a magic machine to appear that eats WADL and generates applications out the other side. At best you're going to get some code stubs. Which is what WSDL does today. And functionally works. I'm not saying it's nice, or pretty; just that it functionally works. It is easier than writing all the SOAP glorp yourself, so I would say such a scheme has a lot of value.
Code generation of data bindings from XML Schema, though, seems fraught with problems.
You can either design a nice document, in which case the resulting code
will be 'ugly', or you can design nice objects and your XML schema will be
be 'ugly'. That's why I'm interested in JSON; perhaps we can have nice
objects AND documents serialized formats!
Yes, people want to describe interfaces, and those descriptions are brittle. If I download a WADL and compile my client today it will break tomorrow when you change the service. If, instead, you use hypertext, link following and request construction based on the hypertext and client state, then the interface won't break when you change servers, or URI structures.
I think of interfaces described here in the same way as Java interfaces. Namely, it's an external description of the system that people interact with. The guts can change, the interface can remain the same. One of the nice features of Java, if you're in the 'binding contracts' business (ie, you use Java). So, no, just because the service changes, does not imply that the client breaks.
But even beyond that, there's no reason someone can't deploy a new interface for a service and leave older interfaces still working. Some people create new versions of their service interfaces every few weeks and support each version for about a year.
Code gen is brittle, and I generally dislike it. But some languages don't require any code-gen, like PHP's SOAP support. Just give it a WSDL, it provides an interface to make calls against, as long as you can figure out what the methods and data are. Even for Java, there a minimizations that can be made; for instance, using dynamic Proxy's against generated Java Interfaces could leave you with a story of just having to generate Java Interface 'stubs', the rest being all handled dynamically.
And of course it would be useful to mention non code-gen uses; even if WADL were totally useless as a code gen device, it might still be handy to have as a documentation format for someone's services. It could also be used to provide validation for the client and server.
... you can't expect me to believe that if you had a carefully crafted WADL you could hand it to WADL2Java and out would pop flickrfs.
Again, of course we're not expecting fully formed apps or filesystems to pop out of a schema-2-language grinder (though I'm curious about what it would mean to plug APP into FUSE). But perhaps something like the "API Kits" listed here? Absolutely! That's what I'm talking about!
Q: You don't expect everything to be built with APP, do you?
Paraphrasing Joe's answer: Not everything, but a lot.
I'm leery of the blog-based legacy of APP. For instance, the second-class nature of binary resources. Also, attributes on collections and entries such as categories, title, etc. A lot of human readable, textual attributes. The kind of stuff you see in ... what is that word again ... oh yeah ... hypermedia.
I'm leery of APP, but I'm hopeful. It's especially nice to think of someone creating all the infrastructure for the CRUD-like interfaces, especially being able to handle HTTP cache validators (I hope). In the end though, you still need to describe the non-Atom data you are transferring over APP.
