3 ms·

I wouldn't necessarily compare it to protobuf, since that in general requires a schema for exact parsing and forwarding. However there are other encodings which

I wouldn't necessarily compare it to protobuf, since that in general requires a schema for exact parsing and forwarding. However there are other encodings which should already cover all the desired features. E.g. CBOR is a standardized JSON-like binary format which has the possibility to store exact types for binary data, dates, etc... 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.

bascule 10y ago
I am curious if you simply missed the numerous places this post refers to CBOR? Such as this: 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 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.