>This is personal opinion, but if you've got a development team >that wants to consume your web services, but doesn't have the >competence to learn how to interpret a SOAP Fault, I say screw 'em. >
I think that depends on why you created the webservice. If it's a weather webservice for example then the chances are you want to hit the broadest market share you can and you don't necessarily have a development team that you're aiming at. >There is a standard mechanism for indicating errors with web >services, and it's faults. It's not like the developers who >don't understand faults are going to be any more gung-ho to >learn a custom reporting mechanism, especially if there are a >bunch of ways to package the same thing (as an array, a >struct, a query, etc). Creating a "custom" mechanism for >indicating errors is only going to piss off the people who >know what they're doing, and expect to get a Fault message >back if there is a problem. > I wouldn't suggest returning anything other than a fault, but I would want to be able to send back some context specific information with the fault rather than a completely generic 'you sent the wrong data' message. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
