Now this isn’t the next MMA fight everyone will be talking about but it is important for us WX developers all the same.

We have been have some conversation about JSON, deserialization, Variants and native JSON variables over on our facebook group this week. And I just happened on an example day that I felt was worthy of a short blog post.

In the past you might have wrote code similar to this when making a call to a RESTful webservice.:

myResponse is restResponse = RESTSend(myRequest)
IF ErrorOccurred() THEN
	RESULT False
ELSE
	retVariant is Variant = JSONTOVariant(myResponse.Content)

        IF retVariant.error = true
            Result False
        ELSE
            // Code to handle return 
        END
END

Well I can’t really fault you for that code, that’s the way I told folks to write it. But there is a downside to that code. If the content returned from the WebService is not in valid JSON format we will get a crash on the JSONToVariant function. And since its an actual fault error the only way to capture the error and code an exceptio is by using the IF Error / WHEN Exception handling functions in WL. Which work but can have unintended consequences and are not the easiest to code and follow. I prefer to have my error handling inline with rest of my code.

The native JSON variable is here to save us from this bad code! The last few versions PCSOFT has been making quite a bit of improvement to their JSON support and with v25, it has allowed us to really clean up our Webservice handling code.

These days we can right the above code like so:

myResponse is restResponse = RESTSend(myRequest)
IF ErrorOccurred() THEN
	RESULT False
ELSE
	retJSON is JSON= JSONToString(myResponse.Content)

        IF ErrorOccurred() THEN
           Result False
        END

        IF retJSON.error = true
            Result False
        ELSE
            // Code to handle return 
        END
END

As you see the code is very similar, once we are to the point of processing the result, we can use the exact same . syntact (retJSON.error) that we used with the Variant. However we have that additional IF ErrorOccured that will fire if myResponse.Content is not valid JSON and doesn’t parse correctly. So now I have error handling inline with the rest of my code, and I no longer have to worry about a crash if a WebService returns something other than valid JSON (you would be surprised how often that happens)

Note: We have also in the past, and part of the FB conversation going on now, used structures defined the way the JSON should be formatted and then done a Deserialize(myStructure,myResponse.Content,PSDJSON), but that was even finickier about the format being correct and also generated a crash if it wasn’t. Using the native JSON variable type avoids all these issues. And if you are wondering about intellisense, you are able to include a sample document / descriptive file when you declare the JSON variable, just like you can for XML variables.

On last time coding the assignment line as:

retJSON is JSON= myResponse.Content

Is valid and works just fine, however if myResponse.Content doesn’t contain valid JSON formatted text, you will once again get a crash, so it is much better to code it with the long hand format as shown above.

So there you have my little JSON stump speech for today, sorry for taking you down the garden path with variants, but at the time it was the only way we had to handle JSON in any reasonable way. And thank you PCSOFT for improving JSON to the point of making it a seamless data type to work with!

• WX