If you want typed data structure transfer, use protocol buffer.
- https://en.wikipedia.org/wiki/Ben_Laurie
They know about protocol buffers.
"Its primary intended use is in cryptographic authentication contexts, particularly ones where JSON is used as a human-friendly alternative representation of data in a system which otherwise works natively in a binary format."
See also the "Content-Aware Hashing" section: The goal of this format is to enable content-aware hashing which produces the same digest for data encoded either as TJSON or a binary format such as Protobufs.
I am using it in conjunction with Protobufs.
That is, the information on the wire doesn't contain enough information to interpret the data -- the schema has to be compiled into or otherwise included in the binary to know what the data means. That's not the case with JSON or TJSON.
Yeah, such a format isn't directly human readable on the wire, but you can just get in into whatever string-like representation you want in your program. And parsers are for sure not harder to write than for most text formats.
There exists a binary analogue of JWT called CWT which is based on the Compact Binary Object Representation (CBOR) standard. Unfortunately you can’t convert JWTs to CWTs without the original issuer re-issuing them and re-signing them in the new format.
Or this:
This is a pervasive problem for anyone who would like to store authenticated/signed data natively in a binary format (e.g. Protobufs, Thrift, capnp, MessagePack, BSON, or CBOR), but also permit clients to work natively with a JSON API without necessarily being aware of a full-and-evolving schema.
JSON is a human-meaningful serialization format, as opposed to all the binary formats named in the post, including CBOR.
See also:
https://github.com/tjson/tjson-spec/issues/26
TJSON could potentially provide non-lossy transcoding to/from the similarly tagged types in CBOR in ways JSON itself cannot.
But if you are using a schema there are now far better alternatives to Protobufs. If you're primarily sending data over the network I've found Google's Flatbuffers to be great. For writing to disk Capn'Proto is similar and equally good. Receiving market data where every nanosecond matters? Simple Binary Encoding (SBE).
All of these formats employ some form of code generation to extract values from what are essentially cleverly packed structs. All data is sent little endian and follow machine word sizes. Not truly cross-language but Flatbuffers has native support for C/C++, Python, Java, Go, C# and 3rd party support for Rust.
You can store whatever format you want on disk, but if you primarily intend to serve proto-consuming clients, you might as well store protos on disk so what you serve to the network is an opaque blob of bytes with no transcoding.
Don't get me wrong, I really love capnp, particularly the CapTP-like features, but I feel like many of the novelties of its IDL/serialization format (possibly ones involving kentonv's original work before he left Google) have actually shipped in proto3. I really love capnp, but there's this handwavy "this is the way the wind is blowing" argument to be made for GRPC, I think.
JSON wins for similar reasons why HTTP 1.1 won. It's a human readable, simple format and performant enough the majority of development cases. Human readable makes debugging easier.
I hope with tjson it will help increase parser speeds with it's type hints.