Recomiendo leer lo siguiente para una discusión bastante decente sobre WADL:
¿Necesitamos WADL?
Personalmente, no soy fanático de WADL. Hay una sobrecarga de ingeniería significativa en el mantenimiento de la documentación legible por máquina (o generada), lo que la hace mucho más frágil (o estrechamente acoplada) que otros métodos de publicación de documentación.
- ¿Debo aprender los conceptos básicos para crear un sitio web receptivo con CSS o aprender solo Bootstrap?
- Cómo mejorar el SEO de un sitio web de una sola página y bajo contenido de texto
- Cómo hacer que Javascript sepa que se seleccionó un elemento desplegable
- ¿Debo usar RubyMine o Sublime Text mientras aprendo Ruby on Rails?
- ¿Cuál es la diferencia entre 301 redirect & rel = canonical?
Fuera del ámbito técnico, nunca he tenido un cliente, cliente, ingeniero, empleado, inversor o prospecto que solicite un documento WADL. Prefiero que mis ingenieros se centren en funciones que resuelvan problemas reales.
Actualización
Puneet solicitó un ejemplo de cómo aprender sobre una API que no es programática, pero que sigue siendo consistente y confiable.
Creo que un gran ejemplo es la documentación de la API de Twitter: la API REST de Twitter
Esto proporciona sustancialmente más que los parámetros, respuestas y fallas: también proporciona contexto, filosofía, ejemplos y tutoriales, cosas que debe consultar para cualquier API.
No me malinterpreten: me encantan los formatos estandarizados como una forma de comunicar información … pero las descripciones programáticas sirvieron mejor a los protocolos SOAP y WS- *, porque las interacciones eran muy complejas.
El enfoque REST moderno para construir API es un cambio de dirección: que los sistemas sofisticados se pueden construir más fácilmente sin la complejidad adicional de SOAP y otros protocolos de “nivel medio”.
