Servicios RESTful - Equivalente a WSDL

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.

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.

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.

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;)

¿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

Existe un RSDL (lenguaje de descripción de servicio relajante) que es equivalente a WSDL. La URL a continuación describe su práctica http://en.wikipedia.org/wiki/HATEOAS y http://en.wikipedia.org/wiki/RSDL . El problema es que tenemos muchas herramientas para generar código de wsdl a java o al revés. Pero no encontré ninguna herramienta para generar código desde RSDL.

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.

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/

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.