rest - from - ¿Cuál es la razón para usar WADL?
wadl java (7)
Para describir RESTful, podemos decir que cada recurso tiene su propia URI. Usando HTTP GET, POST, PUT y DELETE, podemos operar con estos recursos. Todos los recursos son representacionales. 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?
Cuando desee exponer los servicios REST, la mejor manera es generar WADL y compartir con el consumidor (similar a WSDL en servicios web basados en SOAP) .WADL se utiliza para describir el servicio todo en su lugar.
El propósito de WADL es definir un contrato . El contrato especifica cómo una de las partes puede llamar a otra.
Cuando crea una aplicación web desde cero, no necesita contrato y WADL .
Cuando integra su sistema con el otro sistema y puede comunicarse claramente con su equipo de desarrollo, no necesita contrato y WADL (porque puede hacer una llamada telefónica para aclarar las cosas).
Sin embargo, cuando integra un complejo sistema empresarial con varios otros complejos sistemas empresariales mantenidos por varias compañías diferentes (o instituciones federales), entonces créame que desea tener un contrato de comunicación definido lo más estrictamente posible. Entonces necesitas WADL o Open Specification. Lo necesito mal
Las personas con antecedentes empresariales débiles tienden a ver toda la TI 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 puedes llamar o escribir a las personas que desarrollan la aplicación con la que te tienes que integrar. A veces se comunica con una aplicación heredada que ya no se mantiene; se ejecuta y necesita descubrir cómo comunicarse 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 las reglas de integración con claridad. 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 para definir realmente los datos / documentos que está pasando de ida y vuelta. Digamos que está pasando algunos fragmentos XML, en realidad podrían ser parte de un esquema definido.
Ya sea que use o no la DL para generar código no es muy importante para mí. Lo que importa, en mi opinión subjetiva, es que es importante tener un acuerdo formal sobre las interfaces entre los socios comerciales. Incluso si lo que se pasa es obvio, ayuda a identificar quién tiene que arreglar lo que más tarde si alguien cambia la interfaz anterior.
El formato de datos es una parte tan importante de una interfaz como los nombres de los verbos.
WADL atrae a las personas que provienen del mundo SOAP donde es común usar un generador de código para crear un código del lado del cliente basado en el WSDL. No creo que ese mecanismo sea útil en REST ya que crea un código de cliente que está acoplado a los puntos finales del servidor.
Creo que si defines correctamente tus tipos de medios y usas hipermedios dentro de esos tipos de medios, entonces no es necesario tener WADL. La descripción de los puntos finales disponibles está contenida dentro de las definiciones de tipos de medios. Y si ahora se dice a sí mismo, pero application / xml no contiene ninguna información sobre hipervínculos disponibles, entonces digo BINGO. Es por eso que no creo que application / xml y application / json sean los tipos de medios apropiados para REST. No estoy diciendo que no use XML o JSON, simplemente no use el nombre genérico de tipo de medio.
El otro atractivo de WADL es con el fin 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 cliente debe poder escribir un cliente REST sin conocer ninguna URL que no sea la url raíz.
WADL le permite generar código, pruebas y documentación. En realidad, hay algunas herramientas muy útiles que utilizan WADL, aquí puedes ver algunos ejemplos. El problema con el REST "puro", como se describe en la disertación de Fielding, es escribir clientes que admiten Hypermedia (imagínese escribiendo la aplicación de cliente basada en Java Swing, por ejemplo). Con WADL esta tarea está completamente automatizada, y es una gran ventaja en mi opinión. Las pruebas también se vuelven más fáciles.
Antes de dar mi explicación, permítanme decir que la mayoría de los extremistas REST puros lo ridiculizarán hasta los confines de la tierra. No estoy de acuerdo con ellos, ya que prefiero hacer algo, pero para que lo sepan.
WADL es una descripción de una API de servicio web, un poco como WSDL es para servicios web tipo SOAP, que está diseñado para estar más en sintonía con las interfaces RESTful (algo WSDL es pobre en).
Su uso principal en mi experiencia es permitirle generar código de cliente que pueda llamar al servicio (útil si es una API muy grande, que literalmente ahorra horas de trabajo). También sirve para documentar una interfaz similar a REST.