JSON: The Good, The Bad And The Ugly

Over the past several years JSON has become the darling of service message standards.  These days you are shunned if you offer a SOAP service.  The more I use JSON service though the more I question if they are really the answer.

The Good

The main feature of JSON that makes it attractive is size of the data over the wire.  The structure tagging method is a more compact that that of SOAP/XML messages.  For high volume or large message services that could be a critical performance improvement factor.

The fact that JSON was created for use in Javascript also makes it ideal for client side development.  So if you develop with a heavy client Javascript coding you will be pretty happy.

The Bad and The Ugly

I have three main complaints about JSON.  The first is discoverability of services.  Traditional SOAP service have a WSDL service definition associated with them that gives you a list of all the methods in the service and the structure of the calls and returns.  Now if you want to obscure the methods you are publishing then JSON is the right tool for the job from what I have found so far.  If that is not your goal then you better have very complete documentation that is easily accessible to developers.

My next gripe is about readability.  One of the stated goals of the standard is to make it human readable.  I would argue that it can be readable it is only if you tools that will format the message for you.  I’m not saying that it is less readable than XML, but most development tools have formatters built in for XML which is not the case for JSON.  For the moment that means it is harder to inspect JSON messages.

The last thing that frustrates me about JSON are the available tool for interacting with services within Visual Studio.  We can serialize JSON messages, debug through them and even past messages as classes, but we still don’t have tools to make service proxies the way we do SOAP services unless they are part of a WCF service.

The Lesson

If you are creating services for general consumption you should take into account who will be leveraging them and what tools they have available.  Make their life as easy as possible by either providing a discovery mechanism or at the very least complete and up to date documentation.

On the other side, if you are a consumer of JSON services you need to invest time in discovering the tools and techniques that will allow your development to be successful and painless as possible.

In the end we are stuck with JSON until the next defacto standard comes along.  Whether you agree with its appropriateness you need to become well versed with its usage from whatever platform you develop for.