Doesn’t appear to mention what I thought would be the biggest, most obvious advantage: not inheriting javascript’s “all numbers are floats” dain-bramage (i.e. having a true integer datatype). That’s not specific to protocol buffers of course, but still…a definite plus.
Also protobufs and JSON are really for different kinds of services and situations. I work at a company filled with mostly programmers, if I exposed a protobuf + sockets rather than JSON + http based API I would get scalped.
But yes, please do consider that there are things out there that are not JSON.
JSON doesn’t say anything about the representation of numbers, only how to parse them. Of course, many (most?) implementations choose to (de)?serialize JSON numbers only as 64-bit floats for compatibility with Javascript.
Also consider Cap'n Proto: http://kentonv.github.io/capnproto/
I predict that there will be language runtimes where the whole heap is in a
capnprotoformat. The idea of Cap'n Proto is beautiful.Doesn’t appear to mention what I thought would be the biggest, most obvious advantage: not inheriting javascript’s “all numbers are floats” dain-bramage (i.e. having a true integer datatype). That’s not specific to protocol buffers of course, but still…a definite plus.
This really is a huge problem.
Also protobufs and JSON are really for different kinds of services and situations. I work at a company filled with mostly programmers, if I exposed a protobuf + sockets rather than JSON + http based API I would get scalped.
But yes, please do consider that there are things out there that are not JSON.
*Python programmers
JSON doesn’t say anything about the representation of numbers, only how to parse them. Of course, many (most?) implementations choose to (de)?serialize JSON numbers only as 64-bit floats for compatibility with Javascript.