Posts
415
Comments
233
Trackbacks
42
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.

posted on Thursday, July 10, 2014 2:00 PM Print
Comments
Gravatar
# re: JSON: The Good, The Bad And The Ugly
Bram De Buyser
7/11/2014 9:02 AM
It seems as if you're conflating JSON with services that use JSON somewhat. Discoverability of services is a factor for REST services, but not for JSON-WSP, for example. The data format they use is irrelevant to that, the discoverability is part of the service spec. In the same way, you can't point at XML for not making these mistakes, since there it's a part of SOAP spec and not of XML itself.

Technically, it's possible to do SOAP with JSON and REST services with XML. Your arguments would look very different in those cases.
Gravatar
# re: JSON: The Good, The Bad And The Ugly
Quinton
7/14/2014 1:02 AM
I generate WADL's using SOapUI and now my own generators for all my Rest services, this is the Java equivalent of the WSDL.

No standards have been set yet regarding WADL's but it's a good start...

There's also another standard int he works that looks even more promissing, but not much tooling available yet raml.org
Gravatar
# re: JSON: The Good, The Bad And The Ugly
FZelle
7/28/2014 4:46 PM
If you check NancyFx and Amanda https://github.com/MichaelAz/Amanda
then you have a discoverable JSON service ;-)
Gravatar
# re: JSON: The Good, The Bad And The Ugly
EnCey
8/7/2014 2:50 AM
I wasn't aware that XML could assist in discoverability of services. Pretty good for a data-interchange format.

And clearly, the fact that the tools you use cannot format JSON is one of JSON's major flaws. To be honest though, XML has the same problem – neither Notepad nor Office Word format it, making it very unreadable.

Jokes aside, your first complaint about JSON is probably a complaint about REST, or whatever service architecture you're using.

As to tools: Notepad++ and Sublime Text have built-in syntax highlighting and formatting support for JSON. IIRC the new Visual Studio also improves its support.

One advantage I feel you did not mention is that JSON is much, much more readable than XML, especially for larger documents.

Post Comment

Title *
Name *
Email
Comment *  
 

Tim Murphy

Tim is a Solutions Architect for PSC Group, LLC. He has been an IT consultant since 1999 specializing in Microsoft technologies. Along with running the Chicago Information Technology Architects Group and speaking on Microsoft and architecture topics he was also contributing author on "The Definitive Guide to the Microsoft Enterprise Library".



I review for the O'Reilly Blogger Review Program



Technorati Profile

www.flickr.com
Tag Cloud