RESTful Services - WSDL Equivalente

Question

He estado leyendo acerca de REST y SOAP, y entiendo por qué implementar REST puede ser beneficioso con respecto al 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 es necesario" para el WSDL o que sería redundante en el mundo REST, pero no entiendo por qué. ¿No es siempre útil vincularse mediante programación a una definición y crear clases de proxy en lugar de codificación manual? No me refiero a entrar en un debate filosófico, simplemente buscando la razón por la cual no hay WSDL en REST, o por qué no es necesario. Gracias.

Answer 1

Web Application Description Language (WADL) es básicamente el equivalente a WSDL para servicios RESTful pero ha habido una controversia en curso sobre si algo así se necesita en absoluto.

Joe Gregorio ha escrito a nice article about that topic, que vale la pena leer.

Answer 2

WSDL describe puntos finales de servicio. Los clientes REST no se deben acoplar a los puntos finales del servidor (es decir, no se deben tener en cuenta en las URL de antemano). Los clientes REST están acoplados en los tipos de medios que se transfieren entre el cliente y el servidor.

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

Answer 3

WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate

Sin embargo, REST utiliza el protocolo de red mediante el uso de verbos HTTP y el URI para representar un estado de objetos.

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

En REST, si quería crear un nuevo perfil que usaría el verbo POST con un cuerpo JSON o variables del servidor HTTP que describen perfil a la URL /profile

POST debe devolver un lado del servidor genera ID, utilizando el código de estado 201 CREATED y la cabecera Location: *new_profile_id* (por ejemplo 12345)

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

GET sería devolver el estado actual de la /profile/12345

PUT por lo general se utiliza para el lado del cliente genera Identificación

DELETE, obvia

HEAD, obtiene el estado sin devolver el cuerpo.

Con REST debe documentarse a sí mismo a través de una API bien diseñada y, por lo tanto, es más fácil de usar.

This is a great article en REST. Realmente me ayuda a entenderlo también.

Answer 4

El Lenguaje de descripción de aplicaciones web (WADL) es un vocabulario XML utilizado para describir los servicios web RESTful.

Al igual que con WSDL, un cliente genérico puede cargar un archivo WADL y estar inmediatamente equipado 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 para los servicios SOAP de estilo RPC.

Answer 5

Hay un RSDL (lenguaje de descripción de servicio relajante) que es equivalente a WSDL. La siguiente URL 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.

Answer 6

RSDL pretende convertir el reposo 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 admite este formato o Rest Server Solutions con una característica para generarlo automáticamente.

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

Para más detalles sobre el descanso como Hipermedia buscar en el diccionario: http://en.wikipedia.org/wiki/HATEOAS

Nota: Roy Fielding ha criticado estas tendencias en Resto Apis sin el enfoque hypermidia: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Mi Conclusión: Hoy en día, WADL es más común que los Frameworks de Descanso e Integración como Camel CXF ya soportan WADL (generar y consumir), porque es similar a WSDL, por lo tanto, es más fácil de entender en este proceso de migración (SOAP a REST).

Veamos los siguientes capítulos;)

Answer 7

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

Answer 8

no siempre es útil para unir mediante programación a una definición y crear clases de proxy manualmente en lugar de la codificación?

totalmente de acuerdo, es por eso que he utilizado personalmente Swagger.io

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

Así que básicamente utiliza Swagger para describir mis modelos, puntos finales, etc., y luego usar otras herramientas como swagger-codegen para generar las clases de proxy en lugar de codificar manualmente.

Véase también: RAML