Al codificar servicios web, ¿cómo se estructuran los valores devueltos? ¿Cómo manejas las condiciones de error (esperadas e inesperadas)? Si devuelve algo simple como un int, ¿lo devuelve o lo inserta en un objeto más complejo? ¿Todos los métodos web de un servicio devuelven una instancia de una sola clase o crea una clase de valor devuelto personalizada para cada método?¿Cuál es un buen patrón de diseño para los valores de retorno del método web?
Me gusta el patrón de objeto Solicitud/Respuesta, donde encapsula sus argumentos en una sola clase de Solicitud [Operación], que tiene propiedades públicas simples en ella.
Algo así como AddCustomerRequest, que devolvería AddCustomerResponse.
La respuesta puede incluir información sobre el éxito/error de la operación, cualquier mensaje que pueda ser utilizado por la interfaz de usuario, posiblemente el ID del cliente que se agregó, por ejemplo.
Otro buen patrón es hacer que todos estos se deriven de una simple interfaz de IMessage, donde su punto final general es algo así como Proceso (params IMessage [] mensajes) ... de esta manera puede pasar en múltiples operaciones en el mismo solicitud web
+1 por la respuesta de Ben.
Además, sugiero considerar que la respuesta genérica permite múltiples elementos de error/advertencia, para permitir que la respuesta sea lo más comprensible y procesable posible. (¿Le gustaría usar un compilador que se detuvo después del primer mensaje de error, o uno que le dijo tanto como sea posible?)
Si está utilizando servicios web SOAP, entonces SOAP faults son la forma estándar de devolver los detalles del error, donde los mensajes de falla pueden devolver cualquier detalle adicional que desee.
Las fallas de jabón son una práctica estándar donde la aplicación que llama es un cliente de Soap. Hay casos, como un cliente COM que usa XMLHTTP, donde el Soap se analiza como XML y las fallas de Soap no se pueden manejar fácilmente. Todavía no puedo votar, pero otro +1 para @Ben Scheirman.