Servicios RESTful - Equivalente a WSDL


94

He estado leyendo sobre REST y SOAP, y entiendo por qué implementar REST puede ser beneficioso sobre el uso de un protocolo SOAP. Sin embargo, todavía no entiendo por qué no existe el equivalente "WSDL" en el mundo REST. He visto publicaciones que dicen que "no hay necesidad" del WSDL o que sería redundante en el mundo REST, pero no entiendo por qué. ¿No es siempre útil enlazarse mediante programación a una definición y crear clases de proxy en lugar de codificar manualmente? No me refiero a entrar en un debate filosófico, solo a buscar la razón por la que no hay WSDL en REST, o por qué no es necesario. Gracias.


4
Tengo la misma pregunta. Desde la perspectiva del cliente, parece que los servicios de descanso son mucho más difíciles de usar que un servicio WSDL.
w.donahue

4
Me parece que si está exponiendo algo simple, entonces no necesita un WADL o WSDL. Pero si está exponiendo algo tan complejo como SAP ... no puedo imaginar no tener algún tipo de reflexión y espacio de nombres para manejar la plétora de funcionalidades.
Brain2000

¿No se podría considerar el método HTTP OPTIONS como un "equivalente", ya que debería proporcionar información sobre los métodos disponibles y los parámetros necesarios para cualquier acción posible?
Dim13i

Respuestas:


44

El lenguaje de descripción de aplicaciones web (WADL) es básicamente el equivalente a WSDL para servicios RESTful, pero ha habido una controversia en curso sobre si se necesita algo como esto.

Joe Gregorio ha escrito un buen artículo sobre ese tema que vale la pena leer.


1
Gracias Joschi. Leí los artículos, pero el segundo no me pareció demasiado convincente. ¿Qué puntos que aborda le parecieron más valiosos?
skaz

1
Vale la pena señalar que .NET también tiene una forma de publicar metadatos ( msdn.microsoft.com/en-us/library/ms730243.aspx ). Dicho esto, la mayoría de los servicios REST que he visto desarrollados por los grandes sitios incluyen una variedad de clientes descargables desarrollados para los principales lenguajes de programación (Java, .NET, PHP, etc.). En mi opinión, esto supone una gran carga para el proveedor de servicios.
dana

4
@dana: ¿No parece tener mucho sentido escribir un servicio que luego requiere que usted también escriba al cliente?
BlueChippy

19

WSDL describe los puntos finales del servicio. Los clientes REST no deben acoplarse a los puntos finales del servidor (es decir, no deben estar al tanto de las URL de antemano). Los clientes REST se acoplan en los tipos de medios que se transfieren entre el cliente y el servidor.

Puede tener sentido generar clases automáticamente en el cliente para ajustar los tipos de medios devueltos. Sin embargo, tan pronto como comienza a crear clases de proxy en torno a las interacciones de servicio, comienza a oscurecer las interacciones HTTP y corre el riesgo de volver a degenerar hacia un modelo RPC.


4
¿Puedes elaborar un poco más? Me temo que no lo entiendo. Gracias.
skaz

1
Las clases de proxy son una forma de tener la validación de la máquina en tiempo de compilación. Sin ellos, solo tiene documentos escritos manualmente y una "validación" basada en pruebas.
Eric Grange

1
@EricGrange ... y, sin embargo, este enfoque ha funcionado bastante bien para la web hasta ahora.
Darrel Miller

1
@DarrelMiller depende de lo que llames "funcionó bien", esto es como en los 80 cuando todo el mundo escribía sus interops en documentos en papel, así que funciona, pero "bien"?
Eric Grange

4
@BlueChippy Las especificaciones de tipo multimedia se tratan a la antigua. O encuentra un analizador existente para la especificación, o lee la especificación y escribe uno usted mismo. Lo importante a tener en cuenta es que el objetivo es que las especificaciones de tipos de medios sean reutilizables en todas las API. Escribir un nuevo analizador para cada API no sirve para nada. Descansar cuando se hace correctamente es para los beneficios a muy largo plazo de la evolución independiente de cliente y servidor.
Darrel Miller

8

RSDL tiene como objetivo convertir el resto como un hipermedia, en otras palabras, tiene más información que un descriptor de servicio como WSDL o WADL. Por ejemplo, tiene información sobre navegación, como hipertexto e hipervínculos.

Por ejemplo, dado un recurso actual, tiene un conjunto de enlaces a otros recursos relacionados.

Sin embargo, no encontré Rest Clients que admita este formato o Rest Server Solutions con una función para generarlo automáticamente.

Creo que hay un largo camino para llegar a una conclusión al respecto. Vea la larga historia de HTML y W3C vs Browsers lol.

Para más detalles sobre Rest like Hypermedia, míralo: http://en.wikipedia.org/wiki/HATEOAS

Nota: Roy Fielding ha estado criticando estas tendencias en Rest Apis sin el enfoque de hipermidia: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Mi conclusión: Now a Days, WADL es más común que Rest and Integration Frameworks como Camel CXF ya es compatible con WADL (generar y consumir), porque es similar a WSDL, por lo que es más fácil de entender en este proceso de migración (SOAP a REST).

Veamos los siguientes capítulos;)


8

¿No es siempre útil enlazarse mediante programación a una definición y crear clases de proxy en lugar de codificar manualmente?

De acuerdo de todo corazón, es por eso que uso Swagger.io

Swagger es un poderoso marco de código abierto respaldado por un gran ecosistema de herramientas que lo ayuda a diseñar, construir, documentar y consumir sus API RESTful.

Entonces, básicamente, uso Swagger para describir mis modelos, puntos finales, etc., y luego uso otras herramientas como swagger-codegen para generar las clases de proxy en lugar de codificarlas manualmente.

Ver también: RAML


No sabía que Swagger también hacía eso. Pensé que era solo documentación / marco genérico para las API REST
Robert Dundon


3

WSDL es extensible para permitir la descripción de puntos finales y sus mensajes independientemente de los formatos de mensaje o protocolos de red que se utilicen para comunicarse.

Sin embargo, REST usa el protocolo de red usando verbos HTTP y el URI para representar el estado de un objeto.

Los WSDL le dicen en este lugar, si envía este mensaje, realizará esta acción y obtendrá este formato como resultado.

En REST, si quisiera crear un nuevo perfil, usaría el verbo POSTcon un cuerpo JSON o variables de servidor http que describen mi perfil en la URL/profile

POSTdebe devolver una ID generada en el lado del servidor, utilizando el código de estado 201 CREATEDy el encabezado Location: *new_profile_id*(por ejemplo, 12345)

Luego puedo realizar actualizaciones cambiando el estado del /profile/12345uso del verbo HTTP POST, por ejemplo, para cambiar mi dirección de correo electrónico o número de teléfono. Obviamente cambiando el estado del objeto remoto.

GET devolvería el estado actual del /profile/12345

PUT se utiliza normalmente para la identificación generada por el cliente

DELETE, obvio

HEAD, obtiene el estado sin devolver el cuerpo.

Con REST, debería ser autodocumentado a través de una API bien diseñada y, por lo tanto, más fácil de usar.

Este es un gran artículo sobre REST. Realmente me ayudó a entenderlo también.


2
Yo diría que es la restricción hipermedia de REST, más que la restricción de interfaz uniforme que elimina la necesidad de WSDL.
Darrel Miller

3
¿Dónde descubrir "perfil"? ¿Cómo proporciona asistencia cuando en lugar de una, tiene docenas? Todo el resto del servicio se basa en documentos escritos a mano y API escritas manualmente, que requieren mucha mano de obra y son propensas a errores.
Eric Grange

1
Estoy de acuerdo con @EricGrange: ¿podría explicar CÓMO sabe en qué entidades puede realizar operaciones CRUD (L) ... a menos que alguien lo escriba en alguna parte?
BlueChippy

2

La especificación WSDL 2.0 también ha agregado soporte para servicios web REST. Lo mejor del escenario de ambos mundos. El problema es que WSDL 2.0 todavía no es compatible con la mayoría de las herramientas. WSDL 2.0 es recomendado por W3C, WSDL1.1 no es recomendado por W3C pero es ampliamente soportado por herramientas y desarrolladores. Ref: http://www.ibm.com/developerworks/library/ws-restwsdl/


0

El lenguaje de descripción de aplicaciones web (WADL) es un vocabulario XML que se utiliza para describir los servicios web RESTful.

Al igual que con WSDL, un cliente genérico puede cargar un archivo WADL y estar equipado inmediatamente para acceder a la funcionalidad completa del servicio web correspondiente.

Dado que los servicios RESTful tienen interfaces más simples, WADL no es tan necesario para estos servicios como WSDL lo es para los servicios SOAP de estilo RPC.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.