¿Cuál es la razón para usar WADL?

Para describir RESTful podemos decir que cada recurso tiene su propio URI. Usando HTTP GET, POST, PUT y DELETE, podemos operar con estos recursos. Todos los recursos son representativos. Quien quiera utilizar nuestros recursos puede hacerlo a través de un navegador o cliente REST.

Esa es la idea principal de una arquitectura RESTful. Esta arquitectura permite servicios en Internet. Entonces, ¿por qué esta arquitectura necesita WADL? ¿Qué ofrece WADL que el HTTP estándar no ofrece? ¿Por qué WADL necesita existir?

El propósito de WADL es definir un contrato . El contrato especifica cómo una parte puede llamar a otra.

Cuando crea una aplicación web desde cero, no necesita contrato ni WADL .

Cuando integra su sistema con el otro sistema y puede comunicarse claramente con su equipo de desarrollo, no necesita contrato ni WADL (porque puede hacer una llamada telefónica para aclarar las cosas).

Sin embargo, cuando integra un sistema empresarial complejo con varios otros sistemas empresariales complejos mantenidos por varias empresas diferentes (o instituciones federales), créame que desea tener un contrato de comunicación definido de la manera más estricta posible. Entonces necesitas WADL o Open Specification. Lo necesito urgentemente .

Las personas con antecedentes empresariales débiles tienden a ver la TI completa como una colección de aplicaciones web separadas desarrolladas de forma independiente. Pero la realidad empresarial a veces es difícil. A veces ni siquiera puede llamar o escribir a las personas que desarrollan la aplicación con la que tiene que integrarse. A veces te comunicas con una aplicación heredada que ya no se mantiene; simplemente se ejecuta y necesitas descubrir cómo comunicarte con ella correctamente. En tales condiciones necesitas un contrato porque te salva el culo .

En realidad, la generación de clientes es la característica menor de la definición del contrato. Es solo un juguete. El contrato obliga a los malos comunicadores a comunicar claramente las reglas de integración. Esta es la razón principal para usar WADL o Open Specification o lo que sea.

El uso de WADL implica que puede ser lo suficientemente amable como para definir realmente los datos / documentos que está pasando de un lado a otro. Digamos que está pasando algunos fragmentos XML, en realidad podrían ser parte de un esquema definido.

No es muy importante para mí si usa o no DL para generar código. Lo que importa, en mi opinión subjetiva, es que es importante tener un acuerdo formal sobre interfaces entre socios comerciales. Incluso si lo que se pasa es obvio, ayuda a identificar quién tiene que arreglar qué más tarde si alguien cambia la interfaz anterior.

El formato de datos forma parte de una interfaz tanto como los nombres de los verbos.

WADL atrae a personas que vienen del mundo SOAP, donde es común usar un generador de código para crear código del lado del cliente basado en WSDL. No creo que ese mecanismo sea útil en REST, ya que crea un código de cliente que se acopla a los puntos finales del servidor.

Creo que si define correctamente sus tipos de medios y usa hipermedia dentro de esos tipos de medios, entonces no es necesario tener WADL. La descripción de los puntos finales disponibles está contenida en las propias definiciones de tipo de medio. Y si ahora se está diciendo a sí mismo, pero application / xml no contiene ninguna información sobre los hipervínculos disponibles, entonces digo BINGO. Es por eso que no creo que application / xml y application / json sean tipos de medios apropiados para REST. No estoy diciendo que no use XML o JSON, simplemente no use el nombre del tipo de medio genérico.

El otro atractivo de WADL tiene el propósito de documentar los servicios REST. Desafortunadamente, lleva a los desarrolladores por el camino equivocado ya que WADL intenta documentar los puntos finales del lado del servidor. La documentación de los servicios REST debe centrarse principalmente en los tipos de medios. Un desarrollador de cliente debería poder escribir un cliente REST sin conocer ninguna URL que no sea la URL raíz.

WADL te permite generar código, pruebas y documentación. En realidad, hay pocas herramientas muy útiles que utilicen WADL, puede ver algunos ejemplos aquí . El problema con el REST "puro", como se describe en la disertación de Fielding, es escribir clientes que admitan Hypermedia (imagínese escribir una aplicación cliente basada en Java Swing, por ejemplo). Con WADL, esta tarea está completamente automatizada y, en mi opinión, es una gran ventaja. La prueba también se vuelve más fácil.

Antes de dar mi explicación, permítanme decirles que la mayoría de los extremistas REST puros se burlarán de él hasta los confines de la tierra. No estoy de acuerdo con ellos, ya que prefiero hacer algo, pero para que lo sepas.

WADL es una descripción de una API de servicio web, un poco como WSDL es para servicios web de tipo SOAP, que está diseñado para estar más en sintonía con las interfaces RESTful (algo en lo que WSDL es pobre).

En mi experiencia, su uso principal es permitirle generar un código de cliente que pueda llamar al servicio (útil si se trata de una API muy grande, que literalmente ahorra horas de trabajo). También sirve para documentar una interfaz similar a REST.

REST no especifica nada sobre WADL.

Cuando desee exponer los servicios REST, la mejor manera es generar WADL y compartir con el consumidor (similar a WSDL en los servicios web basados ​​en SOAP). WADL se usa para describir el servicio en su lugar.

No es necesario utilizar WADL. Pero, si está trabajando con una aplicación existente compleja y desea implementar la llamada de servicio REST reemplazando la llamada de servicio EJB / SOAP, entonces es muy seguro y una buena práctica utilizar WADL. Al utilizar WADL generar stubs de java del lado del cliente, estará sincronizado con el servicio.

Puede generar el código auxiliar java del lado del cliente utilizando el archivo WADL con la ayuda del complemento wadl2java maven.