rest - generate - wadl vs swagger

¿Por qué la lenta captación de WADL?

Question

He estado investigando WADL y me pregunto por qué no se ha adoptado más ampliamente.

Con la velocidad a la que el uso de REST parece estar creciendo, me sorprende que otros esfuerzos de desarrollo no lo utilicen.

¿Existe un defecto fundamental en su diseño? ¿No es una buena combinación para la cultura que típicamente rodea a los servicios web RESTful, o es algo totalmente distinto?

Answer 1

"RESTO en la práctica: Hypermedia y arquitectura de sistemas" de Jim Webber, Savas Parastatidis e Ian Robinson menciona cuatro preocupaciones:

1. WADL toma una vista estática de la aplicación web por adelantado, donde la Web usa tipos de medios y enlaces para contratos
2. Las herramientas WADL promueven el acoplamiento firme de las abstracciones del cliente y del lado del servicio. Los recursos publicitados desde el servicio se convierten en el modelo de dominio del cliente.
3. WADL no ofrece pistas sobre el orden de las interacciones con los recursos que anuncia.
4. WADL a menudo duplica los metadatos disponibles de los recursos.

Los puntos 1 y 2 son argumentos sobre 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 la HATEOAS .

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 preocupaciones como un implementador de cliente son:

1. ¿Cómo descubro los parámetros de consulta y los encabezados que son compatibles?
2. ¿Cómo puedo encontrar la documentación sobre un tipo de medio de solicitud o respuesta? Incluso si se trata de un tipo de medio registrado por la IANA, seguiré necesitando los esquemas de solicitud / respuesta.

Answer 2

Creo que la razón principal por la cual WADL no gana popularidad es que podría revivir 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 marcos generen automáticamente el código de WADL, tendrán que ocuparse nuevamente de 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 realmente disfrutamos de la generación automática de código :-))