He estado trabajando para crear servicios WCF que operarán independientemente de clientes .Net. Gracias a Google y StackOverflow, he podido crear servicios sencillos xml y json sin envoltorios de jabón y un montón de cosas elegantes de WCF que simplemente no necesito. Ha sido una experiencia dolorosa, de ahí el tema de esta pregunta. WCF tiene errores en el lado del cliente cuando usa WebGet y WebInvoke cuando agrega automáticamente la referencia del servicio.Cliente WCF (Agregar referencia de servicio) odia WebGet y WebInvoke ... realmente, lo hace
Para inspeccionar la comunicación, he estado creando un cliente WCF localmente y pasando todo a través de Fiddler. De esa forma, ya sea que funcione o no, al menos puedo ver lo que el cliente está tratando de enviar. Y cuando finalmente funciona, puedo ver los datos que se envían desde ambos extremos y luego duplicar esta comunicación en un cliente que no sea .Net.
Mi problema actual es que cuando cambio el servicio para esperar datos POST como json (comportamiento de EnableWebScript), el cliente no tiene ni idea, y aún intenta enviar los objetos como xml. Tuve un montón de problemas con las configuraciones del cliente que no se configuraron automáticamente cuando utilizo Agregar referencia de servicio, así que espero que sea algo simple que pueda agregar a la aplicación.config en el cliente. Al usar XML, los objetos que creo y uso en el servicio son serializados automáticamente por el cliente (lo que es más conveniente). ¿Es posible hacerlo como json en la versión actual de WCF?
Cabe destacar que pude descifrar lo que necesito hacer manualmente y ponerlo a trabajar en forma cruda con Fiddler (generador de solicitudes), para poder serializar mis objetos en código y enviar los datos manualmente a través de http post ... así es como lo estoy haciendo en mis clientes non.Net de todos modos. Esta es una pregunta más para comprender mejor los aspectos de WCF y por qué me faltan tantos atributos en el lado del cliente donde hay poca o ninguna documentación disponible para abordar los problemas.
Hombre ... Ojalá hubiera leído esto antes. Hemos pasado básicamente el mismo proceso de pensamiento. Esperaba que el cliente REST "simplemente funcionara" como lo hace el cliente SOAP. –
¿Está vinculado a WCF o tiene la opción de tecnología de carga útil de servidor/servicio? Desde que publiqué esto hace más de dos años, me resistí a usar WCF para nada. Cada servicio que creo o consumo manualmente genera datos xml y/o json livianos, y transfiero mi propia seguridad y todo lo demás que WCF intentó hacer más conveniente para el desarrollador. Creo que es muy revelador que es prácticamente imposible encontrar una API web popular expuesta como servicio de WCF. – Rich
No, no estamos vinculados a WCF, pero creo que podríamos probarlo para uno de nuestros servicios. Construir los componentes del lado del servidor usando WCF fue doloroso hasta que entendimos todo. Aunque ... fue agradable no tener que construir los puntos finales a mano (conseguimos que SOAP/REST/JSON funcionen).Ahora, me doy cuenta de que solo utilizaremos SOAP si estamos usando un cliente .NET y dejamos que otros consuman REST/JSON. –