* It's inefficient compared to schema-based formats like Protobuf - you have to encode key names again and again.
* It's inefficient compared to binary equivalent formats like CBOR - both in space and speed.
* It's less reliable than explicit schema-based formats because it can't be validated (yes I know about JSON-Schema, nobody uses it). You essentially end up with an implicit schema that everyone has to recreate themselves from the documentation - especially if using statically typed languages.
* It's a pain to use from statically typed languages. You have to write the schema in your language, whereas with things like Protobuf it will generate the code for you.
* It doesn't have a proper type for arbitrary binary data. Most people (but not all!) encode it as a base64 string which is not very efficient and not actually a different type to a string, so again you rely on the implicit schema.
* Maps can only have strings as their key type.
* Minor annoyance, but trailing commas would be nice!
* Its number type is not well specified. E.g. does it support uint64?
"Human readable" is overrated. CBOR and similar formats can easily be inspected by humans just by converting them to JSON. The Smile format even starts with a :) smilie as its magic number to make it easily recognisable.
Would you recommend not using compression or encryption on HTTP requests because it stops them being human readable?
* It's inefficient compared to schema-based formats like Protobuf - you have to encode key names again and again.
* It's inefficient compared to binary equivalent formats like CBOR - both in space and speed.
* It's less reliable than explicit schema-based formats because it can't be validated (yes I know about JSON-Schema, nobody uses it). You essentially end up with an implicit schema that everyone has to recreate themselves from the documentation - especially if using statically typed languages.
* It's a pain to use from statically typed languages. You have to write the schema in your language, whereas with things like Protobuf it will generate the code for you.
* It doesn't have a proper type for arbitrary binary data. Most people (but not all!) encode it as a base64 string which is not very efficient and not actually a different type to a string, so again you rely on the implicit schema.
* Maps can only have strings as their key type.
* Minor annoyance, but trailing commas would be nice!
* Its number type is not well specified. E.g. does it support uint64?
"Human readable" is overrated. CBOR and similar formats can easily be inspected by humans just by converting them to JSON. The Smile format even starts with a :) smilie as its magic number to make it easily recognisable.
Would you recommend not using compression or encryption on HTTP requests because it stops them being human readable?