google protocol buffers vs json vs XML [closed]

Question

I would like to know the merits & de-merits of

• Google Protocol Buffers
• JSON
• XML

I want to implement one common framework for two application, one in Perl and second in Java. So, would like to create common service which can be used by both technology i.e. Perl & Java.

Both are web-applications.

Please share me your valuable thoughts & suggestion on this. I have seen many links on google but all have mixed opinions.

Zygapophysis

And you think there's likely to be a concensus here? – Fletafletch

JSON vs XML : https://mcmap.net/q/47519/-json-and-xml-comparison-closed – Westlund

Thanks lot. But would like to know more Protocol Buffers vs JSON. – Zygapophysis

@Fletafletch It' not about consensus, it's about rational choice, about pros and cons, it's good that the question was asked before the meta police started to lower the quality of SO content. – Adrian

I used to object strongly to such questions being closed arbitrarily. But the fact is, if I were consulting to a project that needed to make this choice, I would want a lot more information than typically appears in an SO post; any advice you will get here is anecdotal and based on almost complete ignorance of the requirements and constraints of your particular project. – Gennygeno

It's got a lot of upvotes for something that is "not constructive". – Avenue

the info provided is definitely better than nothing. if the answer contained false or unqualified arguable statements then perhaps it's dangerous. but it doesn't. the points made are either factual or well-evidenced or well-agreed-upon in the community. i don't understand why the question was closed as not constructive. meta police gotta go. seriously. – Ackley

Michael - that's what the upvotes are for. The quality of information in the post depends on the answer written, not on whether that answer appears as a StackOverflow posting. – Aw

Answer 1

Json

• human readable/editable
• can be parsed without knowing schema in advance
• excellent browser support
• less verbose than XML

XML

• human readable/editable
• can be parsed without knowing schema in advance
• standard for SOAP etc
• good tooling support (xsd, xslt, sax, dom, etc)
• pretty verbose

Protobuf

• very dense data (small output)
• hard to robustly decode without knowing the schema (data format is internally ambiguous, and needs schema to clarify)
• very fast processing
• not intended for human eyes (dense binary)

All have good support on most platforms.

Personally, I rarely use XML these days. If the consumer is a browser or a public API I tend to use json. For internal APIs I tend to use protobuf for performance. Offering both on public API (either via headers, or separate endpoints) works well too.

Tien

XML is more work to decode, but validation can be a major advantage over JSON. Validating your XML with a schema before you process a payment transaction it contains gives you an extra layer of robustness. – Hanford

So it is hard to get comparably fast performance out of JSON to Protobuf? – Phip

XML also allows a narrative style where text is alternated with tags inclusions like <value>This is a <attention>narrative style</attention>. Tags could appear <exclamation /> in the middle of text</value>. This is the unique feature of XML when compared with JSON and Protocol Buffers. – Rayraya

@Marc Gravell: How about in terms of forward-compatibility. It's my impression that this is one of protobuf's big selling points? – Thistle

@Thomas true, but there are json and xml serializers that support round-trip of unexpected data etc – Tien

Igor Ganapolsky it is my understanding that this is pretty much conceptually impossible, as there is very little to no parsing necessary for protobuffs, while the processing phase is long and inevitable with json. – Thumbstall

Just to mention that you can use schemas with JSON too. – Eskew

Adding to the points made by @JesusAngulo and CC: JSON Schema can provide documentation and validation of the objects sent: json-schema.org/implementations.html#validators – Condemn