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!