3 ms·
That's a lot of extra bytes you have to send over the wire. Also, I don't think validation makes sense. When sent by the server, it's too limited (would lead to
by wojcikstefan 10y ago
That's a lot of extra bytes you have to send over the wire. Also, I don't think validation makes sense. When sent by the server, it's too limited (would lead to situations where you're doing half the validation in TJSON and half in the client code). When sent by the client, it can't be trusted anyway.
- drawkbox 10y agoTrue if validation is on there. I just put it in to show you could have other easily added validations aside from type (TJSON is locked to just type as it is concat/mashed in one value colon separated). If you just take the "val" and "type" it is really no extra bytes or very minimal but cleaner. { "val":"Hello World", "type":"string" } OR { "s:string":"s:Hello, world!" } Pretty much the same. I guess my personal preference is I don't like to mash values and parse values out of key/value values. In the end all validation is done on the server anyways so types/schemas for JSON are really just a nice to have and should not be relied on unless you control both ends of the pipe.
- imtringued 10y ago>That's a lot of extra bytes you have to send over the wire. Redundant data is not a problem if you combine JSON with gzip. JSON with gzip is basically good enough for everything except fast serialization or deserialization. If you care about that then you should use something like Protocol Buffers or Cap'n Proto.