谷歌协议缓冲区vs json vs XML [英] google protocol buffers vs json vs XML
问题描述
我想知道它的优点和优点.的缺点
- Google协议缓冲区
- JSON
- XML
我想为两个应用程序实现一个通用框架，一个在Perl中，第二个在Java中.因此，希望创建可同时用于两种技术(即Perl& amp; Java.
两者都是Web应用程序.
请与我分享您的宝贵思想和见解.对此的建议.我在Google上看到了很多链接，但都有不同的看法.
Json
- 可读/可编辑
- 可以在不事先了解模式的情况下进行解析
- 出色的浏览器支持
- 比XML冗长
XML
- 可读/可编辑
- 可以在不事先了解模式的情况下进行解析
- SOAP等标准
- 良好的工具支持(xsd，xslt，sax，dom等)
- 非常详细
Protobuf
- 非常密集的数据(小输出)
- 难以在不了解架构的情况下进行强大的解码(数据格式内部模棱两可，并且需要澄清架构)
- 非常快速的处理
- 不适用于人眼(密集二进制)
在大多数平台上都具有良好的支持.
就我个人而言，这些天我很少使用XML.如果使用者是浏览器或公共API，则倾向于使用json.对于内部API，我倾向于使用protobuf来提高性能.在公共API上同时提供这两种功能(通过标头或单独的端点)也很好.
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.
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.
这篇关于谷歌协议缓冲区vs json vs XML的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
