Putting together some scripts from Keith Hill and some of my own code … and using the System.Runtime.Serialization.Json namespace, I’ve managed to make a few pieces to import and export JSON for you to play with. I put it on PoshCode.

This code is very raw at the moment, and quite honestly, the only function here that you can really use on random JSON returned from existing web-services (that is, JSON which doesn’t map to a .Net class) is Convert-JsonToXml.

Convert-JsonToXml is very useful in PowerShell, since XML is a first class PowerShell citizen, and navigable via dot-notation almost as though it were a file-system structure (Hmm… that would actually make an interesting provider, with -Root set as an XML document). In any case, you could also use Select-Xml to dig deeper, and do all of the usual PowerShell stuff against the resulting XML, whereas without this, JSON is just a confusing string.

However, the most interesting JSON conversion in PowerShell would probably be to convert JSON to a series of nested hashtables and arrays (a very accurate translation of the data) — or to new up a dynamic PSobject or collection of objects … I’ll probably write one of those later today, just for fun

But Why JSON?

I honestly don’t know. The more I play with JSON, the more it looks like XML circa 1996 (that is, before the creation of XSLT, XPATH and the other tools which actually make XML useful as a data language). Obviously it’s much lighter than XML: it doesn’t have closing tags, it eschews namespaces … but from where I stand, those benefits don’t make up for the loss of the power of transformations and querying — not to mention the lack of tooling in .Net

I had a look at JAQL and a few similar projects, and all of them are in their infancy, and restricted to javascript. That is, they’re not general-purpose query languages, and they’re not available in server-side programming environments … making JSON (generally speaking) a poor choice for a data language outside of it’s original place: sending well-defined simple data from your back end to your front end.

I certainly wouldn’t choose to use JSON in PowerShell, nor would I consider it a good choice for the output of web-services (bear in mind that without namespaces it also has no standard way of doing versioning either).

Related articles by Zemanta

• XPath and Namespaces in PowerShell (huddledmasses.org)
• What’s in a Namespace (apache.sys-con.com)

2 Responses to “JSON from PowerShell (but why?)”