Solución:
El lenguaje de descripción de aplicaciones web (WADL) es básicamente el equivalente a WSDL para servicios RESTful, pero ha habido una controversia en curso sobre si se necesita algo como esto.
Joe Gregorio ha escrito un buen artículo sobre ese tema que vale la pena leer.
WSDL describe los puntos finales del servicio. Los clientes REST no deben estar acoplados a los puntos finales del servidor (es decir, no deben estar al tanto de las URL de antemano). Los clientes REST se acoplan en los tipos de medios que se transfieren entre el cliente y el servidor.
Puede tener sentido generar clases automáticamente en el cliente para ajustar los tipos de medios devueltos. Sin embargo, tan pronto como comienza a crear clases de proxy en torno a las interacciones de servicio, comienza a oscurecer las interacciones HTTP y corre el riesgo de volver a degenerar hacia un modelo RPC.
RSDL tiene como objetivo convertir el resto como un hipermedia, en otras palabras, tiene más información que un descriptor de servicio como WSDL o WADL. Por ejemplo, tiene información sobre navegación, como hipertexto e hipervínculos.
Por ejemplo, dado un recurso actual, tiene un conjunto de enlaces a otros recursos relacionados.
Sin embargo, no encontré Rest Clients que admita este formato o Rest Server Solutions con una función para generarlo automáticamente.
Creo que hay un largo camino para llegar a una conclusión al respecto. Vea la larga historia de HTML y W3C vs Browsers lol.
Para obtener más detalles sobre Rest like Hypermedia, míralo: http://en.wikipedia.org/wiki/HATEOAS
Nota: Roy Fielding ha estado criticando estas tendencias en Rest Apis sin el enfoque de hipermidia: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Mi conclusión: Now a Days, WADL es más común que Rest and Integration Frameworks como Camel CXF ya es compatible con WADL (generar y consumir), porque es similar a WSDL, por lo que es más fácil de entender en este proceso de migración (SOAP a REST).
Veamos los siguientes capítulos;)