services - wsdl para servicios rest
Servicios RESTful-Equivalente WSDL (8)
¿No es siempre útil vincularse mediante programación a una definición y crear clases de proxy en lugar de codificación manual?
De acuerdo de todo corazón, esta es la razón por la que personalmente he usado Swagger.io
Swagger es un potente marco de código abierto respaldado por un gran ecosistema de herramientas que le ayuda a diseñar, crear, documentar y consumir sus API RESTful.
Así que básicamente uso Swagger para describir mis modelos, puntos finales, etc., y luego uso otras herramientas como swagger-codegen para generar las clases proxy en lugar de codificarlas manualmente.
Ver también: RAML
He estado leyendo acerca de 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 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.
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.
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.
Como los servicios RESTful tienen interfaces más simples, WADL no es tan necesario para estos servicios como lo es WSDL para los servicios SOAP de estilo RPC.
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 revertir. Pero no encontré ninguna herramienta para generar código desde RSDL.
La especificación WSDL 2.0 también ha agregado soporte para servicios web REST. 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/
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 función 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 obtener más información sobre Rest like Hypermedia, mire: http://en.wikipedia.org/wiki/HATEOAS
Nota: Roy Fielding ha criticado estas tendencias en Rest Apis sin el enfoque hypermidia: 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 los Frameworks de Descanso e Integración como Camel CXF ya soporten 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;)
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.
Sin embargo, REST utiliza el protocolo de red mediante el uso de verbos HTTP y el URI para representar un estado de objetos.
Los WSDL le informan que, 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 POST con un cuerpo JSON o variables del servidor http que describan mi perfil en la URL /profile
POST debe devolver una ID generada del lado del servidor, utilizando el código de estado 201 CREATED y la cabecera Location: *new_profile_id* (por ejemplo, 12345)
Luego puedo realizar actualizaciones cambiando el estado de /profile/12345 usando el verbo HTTP POST , digamos para cambiar mis direcciones de correo electrónico o número de teléfono. Obviamente cambiando el estado del objeto remoto.
GET devolverá el estado actual de /profile/12345
PUT se usa generalmente para la identificación generada del lado del cliente
DELETE , obvio
HEAD , obtiene el estado sin devolver el cuerpo.
Con REST debería autoeditarse 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 ayuda a entenderlo también.