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

81

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?

Iguramu
fuente
De Wikipedia : El lenguaje de descripción de aplicaciones web (WADL) es una descripción XML legible por máquina de servicios web basados ​​en HTTP.
Ricardo

Respuestas:

154

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.

Henryk Konsek
fuente
7
"--- SALVA EL CULO" fue la mejor parte. ¿Hay algún generador de código PHP disponible desde el archivo WADL?
Jatin Dhoot
Si no necesita un wadl en una aplicación web. ¿Qué tienes que hacer para enviar una solicitud para recuperar los valores?
Jesse
Puede pedirle al otro equipo que le proporcione el SDK de cliente, por ejemplo.
Henryk Konsek
¿Cómo utilizar e integrar una API web / REST (WA) con documentación insuficiente? Usted 1-sentenció el beneficio de WADL formal (como WSDL):Contract enforces bad communicators to communicate integration rules clearly.
hc_dev
37

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.

Roboprog
fuente
10
El uso de REST requiere que defina los datos / documentos que está pasando de un lado a otro. El problema con WADL es que también intenta definir los puntos finales que no deberían ser parte de la definición de API.
Darrel Miller
4
Derrel, no conozco un solo servicio web para el que haya escrito un cliente, que no tuviera un solo punto final con el que se usara.
Brill Pappin
30

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.

Darrel Miller
fuente
19
WADL también atrae a aquellos que tienen un jefe que dice que debe tener una definición formal en un formato estándar. No digo que sea la mejor manera de hacerlo, solo que algunas veces es útil "marcar una casilla organizativa", por así decirlo. El jefe de uno puede perder el hecho de que es una exageración. Sin embargo, tener el archivo def formal puede evitar que te vuelvan a empujar a la tubería de crack SOAP que todos los demás chicos corporativos geniales están chupando.
Roboprog
2
@Roboprog Documente sus tipos de medios en lugar de los puntos finales. Hay muchos buenos ejemplos en el registro de la IANA. Además, la API de Sun Cloud es un buen ejemplo. Debe convencer a su jefe de que documentar los puntos finales es una mala idea para el futuro.
Darrel Miller
1
También es útil para los desarrolladores que realmente tienen más que hacer que escribir código de cliente todo el día.
Brill Pappin
1
@cboettig Schema es solo un conjunto de reglas de sintaxis, no agregan semántica. Necesita algún otro mecanismo como un tipo de medio o un perfil para agregar semántica.
Darrel Miller
1
@cboettig La gente asocia la semántica a los elementos y atributos con espacios de nombres, pero no existe un proceso estandarizado para hacerlo. Los tipos de medios tienen un registro oficial que apunta a especificaciones que definen la semántica. iana.org/assignments/media-types/application
Darrel Miller
16

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.

Constantino
fuente
16

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.

Brill Pappin
fuente
3
Claro, esa es una buena respuesta. La resistencia parece provenir de la gente incondicional de SOAP, que no quiere DESCANSO en absoluto, y algunos vaqueros de DESCANSO incondicionales, que no quieren ningún trabajo adicional. Tener un documento formal es una buena hoja de parra en una "empresa", incluso si es una pérdida de tiempo para una pequeña API en una nueva empresa.
Roboprog
1
En mi experiencia, hay tres razones principales para algo como WADL: - muchos buenos desarrolladores no conocen REST. - Cuando estás en el reloj, tener un documento o API acelera enormemente las cosas. - Nunca puede asumir que alguien más ha implementado una llamada REST de la misma manera que lo haría. Incluso los evangelistas de REST no pueden ponerse de acuerdo :) Incluso me he encontrado con casos en los que un entorno no permite que se ejecute una llamada DELETE o PUT, por lo que obtiene una interfaz similar a REST que solo usa llamadas GET y PUT ... y entonces la documentación se vuelve crucial.
Brill Pappin
Estoy seguro de que te refieres a OBTENER y PUBLICAR , como en fingir PONER y ELIMINAR con opciones de POST funky. Alas ...
Roboprog
7

REST no especifica nada sobre WADL.

aehlke
fuente
Creo que sí, pero Wadl puede usar dentro del resto, por ejemplo, youtube.com/watch?v=cDdfVMro99s . Parece que wadl admite que los clientes utilicen la función del servidor. Y los clientes solo pueden necesitar tener parámetros y el nombre de la función.
Iguramu
7
Lo que me acaba de describir suena a RPC, no a REST.
aehlke
3

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.

rajendra.penumalli
fuente
0

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.

R.Ranjan
fuente