He estado investigando WADL y me pregunto por qué no se ha adoptado más ampliamente.¿Por qué la captación lenta de WADL?
Con la velocidad a la que el uso de REST parece estar creciendo, me sorprende que otros esfuerzos de desarrollo no lo utilicen.
¿Hay fallas fundamentales en su diseño? ¿No es una buena opción para la cultura que típicamente rodea a los servicios web RESTful, o es algo totalmente diferente?
Creo que la razón principal por la cual WADL no gana popularidad es que podría devolverle la vida a todos esos problemas que tuvimos con SOAP y WSDL. Para mí, el aspecto de interoperabilidad es el aspecto más importante de los servicios web.
Al seguir la forma RESTful de usar estándares HTTP puros, obtiene interoperabilidad "gratis". Una vez que necesite un documento para describir los servicios, habrá diferentes marcos de trabajo del cliente (o diferentes marcos de servidores) que interpretarán este documento de manera diferente. Una vez que los diferentes frameworks generan automáticamente el código de WADL, tendrá que lidiar de nuevo con los problemas de interoperabilidad.
La falta de estándares es la debilidad y la fuerza de la forma RESTANTE, demos una oportunidad al enfoque simple. (A pesar de que nos gusta automático de generación de código :-))
"descanso en la práctica: Hipermedia y Arquitectura de Sistemas" por Jim Webber, Savas Parastatidis, e Ian Robinson menciones cuatro preocupaciones:
Puntos 1 & 2 son argumentos en vinculaciones de cliente dinámicas frente a estáticas. Cuando se utiliza WADL, el implementador del servicio deberá tener cuidado con la compatibilidad con versiones anteriores del esquema a medida que cambie el servicio. Sin WADL, el cliente debe ser flexible en la forma en que interpreta las respuestas.
El punto 3 se refiere al flujo de trabajo. WADL no documenta el orden en que se deben llamar las API. Ambas respuestas de servicio WADL y no WADL ofrecen pistas sobre el orden a través de enlaces si el servicio se implementa de acuerdo con HATEOAS paractice.
El punto 4 postula que los resultados HEAD y OPTIONS pueden ser inconsistentes con la definición WADL. En la práctica, rara vez se implementan o utilizan estos métodos.
Muchas implementaciones de REST son rápidas y sucias. Es fácil implementar un servicio REST solo para mi uso. Es cuando tengo que crear un cliente para un servicio proporcionado por un equipo diferente que quiero documentación. Cuanto más formal, mejor. La documentación legible por código, como WADL, sería lo mejor.
Mis inquietudes como implementador del cliente son:
Curioso lo que la gente piensa en estos días dada la popularidad de cosas como "Swagger". –
No estoy de acuerdo con que la interoperabilidad sea "libre" cuando se utiliza REST. REST no proporciona mágicamente interoperabilidad, no de la manera que una WADL esperaría proporcionar. Reconozco que hay desafíos de interoperabilidad (algunos lo llaman "desajuste de impedancia") cuando se mapea desde, digamos, un XSD en una clase Java, o desde XSD a C#. Pero eso no es necesariamente cierto en todos los enfoques de mapeo. XSD, en particular, es mucho más complicado de lo que debe ser para admitir el caso de interoperabilidad del 80% para los servicios web. Si WADL es apropiadamente modesto en sus objetivos, podría proporcionar un valor real, con bajo riesgo de peligros. – Cheeso
Estoy de acuerdo con Cheeso, REST no proporciona nada 'gratis'. Todavía tiene 'algo de trabajo' que hacer para asegurarse de que está tratando con manzanas (y no con naranjas) particularmente con cargas útiles de datos (ya sea que HTTP esté allí o no). REST también impone problemas cuando se asigna a diferentes objetivos de 'idiomas/conjunto de herramientas'. Esto introduce aún más oportunidades para la falta de adecuación de la impedancia entre dos puntos finales (particularmente cuando cada punto final no está bajo un único punto de control). – gto406
No creo que esta sea la razón detrás de la baja adaptación (De hecho, también puedo argumentar sobre la validez de esta razón, aparte). El motivo de la baja adaptación de wadl en mi comprensión sería su uso en la arquitectura de una solución completa. Muy pocas personas piensan REST y Enterprise SOA juntas. RESTO Los servicios a menudo se colocan en interfaces para JavaScript o aplicaciones móviles para consumir. La adaptación de REST en la arquitectura MicroServices SOA es pequeña pero creciente, esto empujaría cosas como WADL y la generación automática de clientes. –