4 ms·
The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the bene
by denormalfloat 8y ago
The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away.
Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant to look through. By that point a pretty printer is needed, and you might as well have picked any format that has a pretty printer.
Can you add new fields easily? Yeah, but try changing a field name, or its type, or remove a field. This is guaranteed to break some client or server somewhere eventually. I've seen code that uses at least 5 permutations of "Zipcode", "zipcode", "zip_code", etc. I also wouldn't dare try to change it for fear of accidentally breaking our payments processing system.
JSON trades ease of starting up, for suffering when the code base gets big. It's an incredibly alluring trap, as TFA's graph shows.
- humbleMouse 8y agoWhy are you using wireshark to inspect json payloads? Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
- foota 8y agoI would argue that the fact that json doesn't have schema support built in makes it more difficult to handle those issues though.
- humbleMouse 8y agoAvro json schemas and jackson json annotation for POJOS makes json object schemas easy to implement. Versioned object repos make great shared schemas and are easier to manage than xsds. (imo)
- lmm 8y agoAnything would be better than XSD (though I don't think JVM-only is a good idea), but with an object you still don't necessarily know what kind of changes are going to be forward compatible or not. The only thing I've had any success with is something like Thrift or Protocol Buffers, where the canonical definition of your objects is a terse, Algol-like syntax but one that's been designed explicitly with version compatibility in mind, and you know exactly what changes do or don't break compatibility.
- denormalfloat 8y agoWhat shared contracts are there for JSON? The only one I know of is OpenAPI/Swagger, and that's already complicated. Wireshark is used because sometimes we don't have the source code for software we use. The only way to debug is to see what's on the wire.
- joesb 8y agoChanging fieldName is not easy in any data format. Schema has nothing to do with it. If your schema change, you are still going to to break existing client somewhere. It's not like schema can magically tell which field is renamed. Schema also doesn't help different permutation of how a field is spelled. Because, in web world, nobody is going to use your schema. So you just end up with 5 schemas, each with different way to write "zipCode". And if everyone can agree to use your schema, then they can agree to write "zipCode" the same way.
- lmm 8y ago> Changing fieldName is not easy in any data format. > Schema has nothing to do with it. If your schema change, you are still going to to break existing client somewhere. It's not like schema can magically tell which field is renamed. If you use something like thrift or protocol buffers then the field on the wire is numbered, and so you can change the human-friendly name that's used in code without breaking wire-level compatibility.
- AgentME 8y agoXML has browser support too.