Watching WADL

I'm following the discussion of RESTful Web description in general, and
WADL in particular, with both difficulty and interest. The first hurdle
that a RESTful description format faces is probably the biggest; how
it's used by clients. My experience is that WADL provides most of its
value on the server-side (e.g., for in-development service modelling,
documentation, and review, as well as limited code generation), but
much discussion keeps on circling around to the client side, perhaps
because of the well-worn footpath off the cliff that WSDL provided. If
clients use a WADL file to generate static code that calls the described
service without checking to see if the WADL has changed, they're going
to be tightly coupled to the WADL definition, and therefore no better
than WSDL or any other interface description. Blech. On the other hand,
if you use the WADL at runtime to dynamically create the URLs and
representations you send and parse the ones you receive, it's all good,
and in this way WADL is acting like a Web format should -- using
hypertext (in this case, a generic XML format) as the engine of
application state. In this way, it's no different than the APP service
document format or HTML forms, except that WADL is less
application-specific in the first case, and more flexible in the latter...
I think there will be two ways to get a (somewhat) RESTful Web service
into the world, for the foreseeable future. One will be to work with a
group of people to identify a broad problem space, standardise one
(or a few) media types, defining their semantics, and an
application-specific format that glues them together into an interface.
Atom Publishing Protocol is a great example of this, and it certainly
has legs. The other will be to skip the huddle, define your own formats
and semantics, and throw it over the wall, knowing that you'll get your
problem solved in the short term, but without the considerable leverage
of a widely adopted and understood format and interface...