How do you then handle the exception on the ws consumer-side thrown by the ws producer-side?
I’m now using SOAP because I can use <cfinvoke> easily and not worry about JSON messing up my data types. However its disadvantages are:
- WSDL must have a return type (i.e. can’t return custom exception struct easily)
- WSDL needs reloading during development
- exception is not transmitted over nicely nor very helpful, and
- performance is quite slow
Other then SOAP, what would you use to do CF-to-CF method call? I can think of these alternatives:
<cfhttp>to?method=remoteMethod
Cons: need to use a custom json serializer because CF’s would mess up datafield like phone number (serializes to a float) or dates (serializes to human-readable date)
<cfhttp>to.cfm
Cons: need to make sure onRequest and other layouts are not rendered (cannot use onCFCRequest())
Any comment or suggestion?
Lately I’ve been preferring cfhttp to a URL that provides a JSON result over CFC/WSDL based webservices. I’ve found this is easier for a couple of reasons:
1) This works well when consuming from either CF or jQuery (or really any other consumer, really).
2) You have more control over the output, which is what it sounds like you’re experiencing.
For error trapping on the client side, I think server-side error trapping is pretty straightforward. Just watch for a 404, and handle the response body as appropriate (email it, log it, or report it to the user). Regarding the JSON serializing problems, that hasn’t been an issue I’ve come across (yet).
When I have used wsdl-based webservices, we trap for errors with a try / catch and then just email the error dump back to the developers. This is not great, though, since the real error is usually buried in the stack trace and obscured by all of the CF abstraction layers involved. Basically all this tells me in these cases is that I need to go hunting for the error log on the server, so I can find the real source of the problem.