Enterprise Integration Zone is brought to you in partnership with:

Tim Murphy is a Solutions Architect at PSC Group, LLC (www.psclistens.com). He has been an IT Consultant since 1999 specializing in Microsoft technologies and Software Architecture. Tim is a co-founder of the Chicago Information Technology Architects Group as well as a contributing author of the book The Definitive Guide to the Microsoft Enterprise Library and part of the Influceners program on the geekswithblogs.net site. He has also spoken at the nPlus1 ArcSummit in Chicago, the Chicago Code Camp and has appeared on the Thirsty Developer podcast. Tim is a DZone MVB and is not an employee of DZone and has posted 56 posts at DZone. You can read more from them at their website. View Full User Profile

JSON: The Good, The Bad And The Ugly

  • submit to reddit

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.


Published at DZone with permission of Tim Murphy, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ferdinando Colu... replied on Wed, 2014/07/16 - 9:12am

(please forgive my bad english)

I think you are not comparing two message formats: XML and JSON, but two methodologies: namely SOAP and REST. 

"REST+JSON" is probably better than "SOAP+XML" because it is simpler and cleaner; it wins because the latter is not good, not because it is *absolutely* good ...

when a developer has two choices, he/she obviously get the one that works better for him/her.

but I agree with you: some framework/tool should be useful; I use a little tool, JsonViewer, to obtain a visual representation of a JSON  string, and it is very useful.

maybe the problem is that the vendors have not found ground for their businness in the REST+JSON arena ...

thank you.

Nando :)

Philippe Lhoste replied on Wed, 2014/07/16 - 10:03am

Maybe http://json-schema.org/ is worth a look for you? I see Visual Studio is even mentioned in the tools.

Davide Piazza replied on Wed, 2014/07/16 - 11:54am

Hi Tim, 

did you already have a look at raml.org  project?

Scot Hatt replied on Wed, 2014/07/16 - 9:03pm

A HATEOAS compliant RESTful interface backed by swagger and jackson self decribes and responds with JSON that can then be modelled on a backend consumer or unwrapped directly from JavaScript asynch calls.  An equivalency to this would be XML data types passed around through SOAP minus the ease of use on the JavaScript side of things dealing with the resultant object from the XML. The concept of JSON as an interface seems a little off to me since it is 'Object Notation' not 'Interface Notation.' This suggests that it is a fully implemented and populated data type discovered through an actual interface paradigm like REST.

Wang Sy replied on Thu, 2014/07/17 - 12:56am

Good comments.

But I think you could find some solutions for your questions by online search

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.