Links

Tuesday, June 05, 2007

WADL waffling

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.

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.