web services - tutorial - ¿Por qué exactamente querría usar un WSDL para describir un servicio web?
wsdl tutorial español (6)
Tengo problemas para entender por qué un WSDL sería tan beneficioso, cuando la verdad es que la definición del servicio no es legible para el ser humano, y la mayoría de los desarrolladores usarán herramientas automatizadas para consumirlo y generar objetos en la aplicación. ¿Por qué no es más fácil para un proveedor de servicios definir un esquema XML simple, y simplemente dígame en la documentación qué puedo obtener y cómo puedo obtenerlo? Comprendo todo el aspecto de la "definición universal", pero todo parece tan complicado para mí. La mayoría de las API para sitios sociales usan una arquitectura REST básica, y lo único que hacen es darle una representación esquemática de los datos que recibirá. En serio, debo estar perdiendo algo aquí.
En un momento, WSDL era popular y estoy seguro de que para muchas empresas (y grandes sistemas SOA), WSDL todavía está en uso. Pero está en lo cierto, la adopción de REST ha sacado a WSDL del mapa un poco una vez que "entra en escena".
Tomemos como ejemplo Amazon S3. Ofrecen un WSDL junto con la API REST. Leí en alguna parte que el 98% de los usuarios de S3 están utilizando la API REST y Amazon está considerando descartar la compatibilidad con WSDL.
REST está limpio. WSDL a menudo depende de otras herramientas para analizarlo o crear funciones automáticamente para que su aplicación se beneficie de los servicios ofrecidos por WSDL. REST también tiene la ventaja de ser mucho más natural al aprovechar HTTP y no confiar realmente en nada más. Si obtienes SOAP en la mezcla y los muchos otros acrónimos que van junto con WSDL, terminas teniendo mucho en tus manos ...
Entonces, ¿qué "esquema XML simple" propondría que permita que las herramientas den el mismo nivel de soporte de generación de código que ahora?
Creo que los diseñadores de WSDL argumentarían que ya están dando el esquema más simple que pudieron y que expuso todo lo que necesitaban. No estoy diciendo necesariamente que esté de acuerdo, pero ser capaz de autogenerar clientes es muy poderoso.
Este enlace debería ayudarte.
http://www.prescod.net/rest/rest_vs_soap_overview/
Este es un gran recurso para ayudar a aquellos que no entienden la disputa SOAP vs REST. Son diferentes herramientas. Úselos para que resuelva su problema de la manera más eficiente.
Para mí, WSDL parece ser otro ejemplo de "arquitectura de cebolla" sobre-diseñada, como los EJB Java originales. Muchas capas y lágrimas.
Por un lado, WSDL es lo que las herramientas automatizadas usan para generar objetos. Y ya es un formato XML bastante simple, pero estoy empezando a creer que una herramienta que haga que escribir XML sea más fácil nunca existirá. No creo que nadie diga que es un protocolo mejor que REST, pero salió primero, tiene una gran compatibilidad con herramientas (Visual Studio lo abstrae por completo al crear y consumir servicios), y es un estándar, por lo que probablemente siga siendo popular para Un rato.
WSDL es un archivo de representación XML y un estándar de comunicación para que cualquier sistema externo se comunique con su servicio web independientemente de las plataformas o tecnologías de implementación. Para su información, los servicios RESTful pueden usar un archivo de lenguaje de definición llamado WADL para describir el servicio también. Por lo tanto, no se trata solo de servicios web.