Chris Ferris picks up a discussion the community has had a few times before:
Bottom line, for me, is that I have long believed that RESTful syetems would benefit from addition of exposed metadata in the form of descriptions such as those proposed by WSDL2.0 and WADL. Certainly, from my perspective, REST and a description of the constraints on an application/system's interface are not mutually exclusive of one another.
This is a reaction to a post by Steve Vinoski, who wrote:
One problem I noticed, though, was that the client developers asked for a “REST-like interface” and also for a document listing all resource URIs, and for each one, the HTTP verbs that apply to it, the representations available from it, and what status codes to expect from invoking operations on it. Those two requests are sort of mutually exclusive, depending on what “REST-like” means; for a proper RESTful system, you don’t need a document like that, at least not the type of document they’re asking for.
In my opinion, the key point is not that something is wrong with a description language; what's wrong is to keep it in isolation from the actual resources. If I do a GET on a resource and the server sends an HTML form, this is a perfectly fine description for a particular use case; the same could be done e.g. with (something like) WADL, which would make it perfectly RESTful.
The other issue is that description languages, at least the 2 you mention, can’t sufficiently express the URI space for many types of services. Services that can derive resources dynamically from a submitted URI (and not just through query string arguments) are becoming common. Even using URI templates, these description formats are limited to an effectively static URI list. Supporting “late-bound” resources is a huge part of promoting “serendipitous reuse”. What good is it to only describe the most obvious capabilities of a system?