буферы протокола Google против json против XML

Question

буферы протокола Google против json против XML

186

Я хотел бы знать достоинства и недостатки

Буферы протокола Google
JSON
XML

Я хочу реализовать одну общую структуру для двух приложений: одну на Perl и вторую на Java. Таким образом, хотелось бы создать общее обслуживание, которое может использоваться как технологией, то есть Perl и Java.

Оба являются веб-приложениями.

Пожалуйста, поделитесь со мной своими ценными мыслями и предложениями по этому поводу. Я видел много ссылок на google, но у всех есть смешанные мнения.

Manoj Kathiriya 25 дек. 2012, в 05:24

Источник

9

И вы думаете, что здесь может быть консенсус?
Barmar 25 дек. 2012, в 07:16
0

JSON против XML: stackoverflow.com/questions/4862310/json-and-xml-comparison
rai.skumar 25 дек. 2012, в 07:16
1

Большое спасибо. Но хотел бы узнать больше протокола буферов против JSON.
Manoj Kathiriya 25 дек. 2012, в 07:24
16

@ Barmar Речь идет не о консенсусе, а о рациональном выборе, о плюсах и минусах, хорошо, что вопрос был задан до того, как мета-полиция начала снижать качество контента SO.
Boris Treukhov 18 нояб. 2014, в 06:40
0

Я имел обыкновение возражать против того, чтобы такие вопросы были произвольно закрыты. Но дело в том, что если бы я консультировался с проектом, который должен был сделать этот выбор, я бы хотел гораздо больше информации, чем обычно появляется в SO сообщении; Любой совет, который вы получите здесь, является анекдотичным и основан на практически полном незнании требований и ограничений вашего конкретного проекта.
Michael Kay 30 дек. 2016, в 23:23
0

У него много голосов за то, что "неконструктивно".
pojo-guy 23 фев. 2017, в 01:00
0

предоставленная информация определенно лучше, чем ничего. если ответ содержал ложные или безоговорочные спорные утверждения, то, возможно, это опасно. но это не так. высказанные замечания являются либо фактическими, либо подтвержденными, либо хорошо согласованными в сообществе. Я не понимаю, почему вопрос был закрыт как неконструктивный. Мета полиция должна идти. шутки в сторону.
BaltoStar 02 март 2017, в 04:01
0

Майкл - вот для чего нужны противники. Качество информации в посте зависит от написанного ответа, а не от того, отображается ли этот ответ как публикация StackOverflow.
Dan Nissenbaum 23 июль 2017, в 21:54

Показать ещё 6 комментариев

Теги:

xml

json

protocol-buffers

data-serialization

1 ответ

Ещё вопросы

И вы думаете, что здесь может быть консенсус?
JSON против XML: stackoverflow.com/questions/4862310/json-and-xml-comparison
Большое спасибо. Но хотел бы узнать больше протокола буферов против JSON.
@ Barmar Речь идет не о консенсусе, а о рациональном выборе, о плюсах и минусах, хорошо, что вопрос был задан до того, как мета-полиция начала снижать качество контента SO.
Я имел обыкновение возражать против того, чтобы такие вопросы были произвольно закрыты. Но дело в том, что если бы я консультировался с проектом, который должен был сделать этот выбор, я бы хотел гораздо больше информации, чем обычно появляется в SO сообщении; Любой совет, который вы получите здесь, является анекдотичным и основан на практически полном незнании требований и ограничений вашего конкретного проекта.
У него много голосов за то, что "неконструктивно".
предоставленная информация определенно лучше, чем ничего. если ответ содержал ложные или безоговорочные спорные утверждения, то, возможно, это опасно. но это не так. высказанные замечания являются либо фактическими, либо подтвержденными, либо хорошо согласованными в сообществе. Я не понимаю, почему вопрос был закрыт как неконструктивный. Мета полиция должна идти. шутки в сторону.
Майкл - вот для чего нужны противники. Качество информации в посте зависит от написанного ответа, а не от того, отображается ли этот ответ как публикация StackOverflow.

Marc Gravell · Accepted Answer · 2012-12-25T10-31-00.000Z

Json

доступно для чтения/редактирования
может быть проанализирован, не зная схему заранее
отличная поддержка браузера.
менее подробный, чем XML

XML

доступно для чтения/редактирования
может быть проанализирован, не зная схему заранее
для SOAP и т.д.
хорошая поддержка инструмента (xsd, xslt, sax, dom и т.д.)
довольно многословный

Protobuf

очень плотные данные (малый выход)
трудно прочно декодировать, не зная схемы (формат данных является внутренне неоднозначным и требует уточнения схемы)
очень быстрая обработка
не предназначен для глаз человека (плотный двоичный)

У всех есть хорошая поддержка на большинстве платформ.

Лично я редко использую XML в эти дни. Если потребитель является браузером или публичным API, я использую json. Для внутренних API я использую protobuf для производительности. Предлагая как публичный API (либо через заголовки, либо отдельные конечные точки), тоже хорошо работает.

XML - это больше работы для декодирования, но валидация может быть основным преимуществом перед JSON. Проверка вашего XML с помощью схемы перед обработкой платежной транзакции, которую он содержит, дает вам дополнительный уровень надежности.
Так сложно ли добиться сравнительно высокой производительности от JSON до Protobuf?
XML также допускает стиль повествования, в котором текст чередуется с включениями тегов, такими как <value>This is a <attention>narrative style</attention>. Tags could appear <exclamation /> in the middle of text</value> . Это уникальная особенность XML по сравнению с JSON и Protocol Buffers.
@Marc Gravell: Как насчет прямой совместимости. У меня сложилось впечатление, что это одна из главных выгодных вещей от protobuf?
@Thomas true, но есть сериализаторы json и xml, которые поддерживают передачу неожиданных данных и т. Д.
Игорь Ганапольский, насколько я понимаю, это практически концептуально невозможно, так как для протобаффов практически нет необходимости в синтаксическом анализе, а фаза обработки в json является длинной и неизбежной.
Просто отметим, что вы можете использовать схемы и с JSON.
Добавление к замечаниям, сделанным @JesusAngulo и CC: JSON Schema может предоставить документацию и проверку отправленных объектов: json-schema.org/implementations.html#validators