CODEWITHSUNDEEP
web-servicescoldfusion
Henry
Henry

Reputation: 32885

Coldfusion-to-Coldfusion web service call: SOAP vs cfhttp method call vs cfhttp post?

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:

Other then SOAP, what would you use to do CF-to-CF method call? I can think of these alternatives:

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)

Cons: need to make sure onRequest and other layouts are not rendered (cannot use onCFCRequest())

Any comment or suggestion?

Upvotes: 2

Views: 1346

Answers (2)

Shawn Holmes
Shawn Holmes

Reputation: 3762

This is a borderline opinion question, so I'll address each item you've asked with possible solutions.

How do you then handle the exception on the ws consumer-side thrown by the ws producer-side?

Solution: Decide upon a common communication "package" (say, a struct with certain keys) that you will always return, regardless of an exception being thrown or not. For example:

result = StructNew();
result.error = false
result.msg = "Success";
result.data = myQuery

result now can always be returned, and an expectation of keys 'error', 'msg', and 'data' can be referenced by the client.

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)

Solution: Switch from JSON to XML:

  1. Set the attribute returnFormat="plain"
  2. Set the attribute returntype="XML"
  3. Re-handle your data in the body of your methods so that the returned object is XML

OR

  1. Use a new JSON Serializer/Deserializer: JSONUtil Project

Cons: need to make sure onRequest and other layouts are not rendered (cannot use onCFCRequest())

Solution:

  1. Move your service CFCs to their own subdirectory which itself contains its own webservice-driving Application.cfc
  2. Construct aforementioned Application.cfc to hide/destroy onRequest() event (Source: Ben Nadel)

Note: #2 also resolves your issue above, quote:

WSDL needs reloading during development

Upvotes: 1

Jake Feasel
Jake Feasel

Reputation: 16955

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.

Upvotes: 1

Related Questions