Estoy tratando de escribir un servicio web para las especificaciones y requiere un cuerpo de respuesta diferente dependiendo de si el método se completa con éxito o no. He intentado crear dos clases diferentes de DataContract, pero ¿cómo puedo devolverlas y hacer que se serialicen correctamente?¿Hay alguna manera de devolver diferentes tipos de un método WCF REST?
La respuesta es sí pero es complicado y se pierde una gran escritura en su interfaz. Si devuelve un Stream, los datos podrían ser xml, texto o incluso una imagen binaria. Para las clases de DataContract, debe serializar los datos usando DataContractSerializer.
Vea el BlogSvc y más específicamente el RestAtomPubService.cs WCF service para más detalles. Tenga en cuenta que ese código fuente también le mostrará cómo aceptar diferentes tipos de datos en un método de descanso WCF que requiere un mapeador de tipos de contenido.
Si está utilizando un enlace basado en xml, entonces creo que no hay forma de hacerlo. Una solución simple en ese caso sería simplemente tener parte del indicador de mensaje si hubiera una falla, y almacenar la información de falla en algún lugar si fuera necesario. Para un enlace JSON, puede usar un método que devuelve un objeto y luego devolver dos tipos diferentes de objetos. Si recuerdo correctamente (lo cual es raro), eso es posible porque la clase JavaScriptSerializer usa la reflexión si el objeto está limpio de atributos de serialización.
La mejor manera de indicar que su servicio web WCF ha fallado sería lanzar una FaultException. Hay configuraciones en los archivos web.config de su servicio que permiten que todo el mensaje de error pase al cliente como parte del error.
Otro enfoque puede ser heredar ambos resultados de la misma clase base o interfaz. El servicio devolvería una instancia del tipo base. A continuación, puede utilizar el atributo KnownType para informar al cliente que pueden devolverse varios tipos. Ahora que lo pienso, podría ser posible usar Object como tipo base, pero no lo he intentado.
Al fallar cualquiera de estos enfoques, puede crear un objeto de resultado personalizado que contenga tanto un resultado como propiedades de error y su cliente podrá entonces decidir qué curso de acción tomar. Tuve que usar este enfoque para Silverlight 2 porque Beta 2 aún no admite completamente los contratos de falla. No es bonito, normalmente no lo recomendaría, pero si es la única manera de hacerlo funcionar o sientes que es el mejor enfoque para tu situación ...
Si tienes problemas con ADO.NET Data Services, Tengo menos experiencia allí.
Here's some information en FaultContracts ejecución
No encontré ese archivo (RestAtomPubService.cs) en la fuente, ¿lo perdí o lo he eliminado? Gracias. –
Desde entonces, nos hemos alejado de WCF para REST porque no era lo suficientemente flexible para nuestras necesidades. Creo que el archivo aún debería estar allí en la historia. – JarrettV