Joe Gregorio answered some questions about WADL in his post"Do we need WADL?".Also note that Leonard Richardson has chimed inrecently on the WADL issue.And I of course have some different thoughts. :-)
Quotes from Joe inbold 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 theother side. At best you're going to get some code stubs. Which is whatWSDL does today. And functionally works. I'm not saying it's nice, or pretty; just that it functionally works. It is easier than writing allthe 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 codewill 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 niceobjects 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 nicefeatures of Java, if you're in the 'binding contracts' business (ie, youuse Java). So, no, just because the service changes, does not imply thatthe client breaks.
But even beyond that, there's no reason someone can't deploy a new interfacefor a service and leave older interfaces still working. Some peoplecreate new versions of their service interfaces every few weeksand support each version for about a year.
Code gen is brittle,and I generally dislike it. But some languages don't requireany code-gen, like PHP's SOAP support. Just give it a WSDL,it provides an interface to make calls against, as long as youcan figure out what the methods and data are. Even for Java,there a minimizations that can be made; for instance, usingdynamic Proxy's against generated Java Interfaces could leaveyou 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 uselessas a code gen device, it might still be handy to have as adocumentation format for someone's services. It could alsobe 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 (thoughI'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, thesecond-class nature of binary resources. Also, attributes oncollections 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 niceto think of someone creating all the infrastructure for theCRUD-like interfaces, especially being able to handleHTTP cache validators (I hope). In the end though,you still need to describe the non-Atomdata you are transferring over APP.