I’ve discussed this issue several times before with Brian Aker who works with me at HP’s Advanced Technology Group and in the past I have been hit with the issues I’m going to talk about here.
JSON is human readable and easy to parse, that cannot be denied and for prototyping is good in a pinch. The first problem comes when you need to validate data. I’ve been stung many times by one end trying to read/write the JSON in a slightly different format to the other end, the end result is always not pretty. This is one advantage that XML and SOAP has going for it over JSON since validation is easier. I’m personally not a fan of XML but there are many who are.
There are additional problems when you start using mobile platforms. Mobile networks are unreliable, you may have a good 3G signal but it is possible to only get dial-up speed through it due to all the other users. JSON is verbose, XML more so which requires more data transfer. Whilst this can be resolved with protocol compression it will require additional decoding on the client side to do this. In addition data conversion will be needed in many cases for numeric fields.
For many applications the data you are sending is directly from a database or at least data that has been modified since being read from a database. So you will likely want the data model for your messages to match this as much as possible. This is where Google’s Protocol Buffers fit nicely.
Protocol Buffers allow you to specify a schema for the data in a human readable format, it actually looks a little like a database schema. They will automatically validate the data for you and have versioning built-in. This means you can make your code easily backwards and forwards compatible.
There is a positive and negative side to the data transfer of Protocol Buffers. It is a binary protocol. This means it takes up minimal bandwidth on the wire but also means that it is very hard to interpret the data without the schema. The same could be said if you were given InnoDB table data without the schemas. It also means it may be possible to compress the data further with something like LZO or DEFLATE.
I recommend application developers consider Protocol Buffers instead of JSON when they are next developing a server/client application.
via Planet MySQL
Why JSON is bad for applications