JSON в не-Javascript-приложениях - PullRequest
5 голосов
/ 26 октября 2009

Я хочу сохранить и получить большое количество данных типа пара ключ-значение по проводам. Уместно ли для меня использовать JSON для этой цели против XML?

Используется ли JSON в приложениях, отличных от Javascript?

Есть ли преимущества использования JSON для этой цели по сравнению со старым добрым XML?

Ответы [ 8 ]

14 голосов
/ 26 октября 2009

JSON подходит для этого использования и будет более компактным, чем XML. (Мы широко используем его в приложениях, отличных от Javascript, и разрешаем пользователям наших веб-служб REST указывать, хотят ли они данные в представлениях XML, JSON или даже XHTML.)

Обновление: где пропускная способность важна, вы, вероятно, можете получить сжатие на 50-70% путем GZIP-кодирования / декодирования вашего XML или JSON. См. GZipStream .

6 голосов
/ 26 октября 2009

Поскольку JSON широко используется серверами веб-приложений для связи с Javascript в браузере (AJAX), существует множество библиотек кодирования / декодирования JSON для каждого языка, который вы можете себе представить. Например, Python имеет на выбор 6 разных реализаций.

Основным преимуществом использования JSON для «большого объема» данных является то, что время анализа для декодирования данных несколько меньше, чем для анализа XML. Теперь возможно, что ваши пары ключ-значение достаточно просты, чтобы время синтаксического анализа не имело значения, но если значения содержат какие-либо составные объекты, то JSON будет быстрее.

4 голосов
/ 26 октября 2009

Я нахожу JSON менее многословным, чем XML, и в разработке есть очень хорошая база данных под названием CouchDB , которая позволяет напрямую сохранять / искать документы JSON.

2 голосов
/ 27 октября 2009

Будет ли это лучше для вас, будет зависеть от ваших приоритетов, таких как скорость или гибкость.

Я переместил приложение C # для использования JSON, потому что скорость была для меня самой важной проблемой. Я сам сериализировал данные на сервере и удалял все лишнее, например имя каждого свойства, чтобы ускорить передачу, и я обнаружил, что пришло время отправить запрос на сервер, получить ответ, и процесс был быстрее JSON, чем использование веб-сервиса или возврат XML.

Для десериализации из C # у вас есть несколько опций в http://json.org.

Итак, прежде чем вы решите внести изменения, вам нужно пройти несколько модульных тестов, а затем получить несколько номеров, сделав один и тот же вызов client -> server -> client около 100 раз, чтобы получить лучшие результаты.

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

Если вам потребуется гибкость сортировки или обработки другими способами, такими как использование XML LINQ, то вы либо преобразуете информацию в список и используете LINQ, но, опять же, вы можете добавить тесты, чтобы увидеть, что влияние этого будет на ваше приложение.

По сути, я считаю, что если у вас есть время, прежде чем делать какие-либо архитектурные изменения, сначала проведите тест, а затем решите, имеет ли смысл изменение, основываясь на числах.

2 голосов
/ 26 октября 2009

Я согласен с другими в отношении удобства использования JSON, но с одной оговоркой: JSON не позволяет вам предоставлять дополнительную информацию о данных. Если все, что вы хотите использовать, это пары имя-значение, где все значения являются строками, то JSON подойдет.

Хорошо, кто-то, вероятно, только что проголосовал за меня, потому что спецификация JSON различает строки, числа, логические значения и массивы. Но мой ответ на этот вопрос: какой номер вы получаете? 32-разрядное целое число или тысяча цифр с плавающей точкой?

XML, для сравнения, позволяет хранить метаданные в атрибутах. Например, атрибут xsi:type, как определено схемой XML. Конечно, обеим сторонам все еще приходится договариваться о том, что означают атрибуты, но во многих случаях метаданные важны.

2 голосов
/ 26 октября 2009

Конечно, на самом деле JSON намного лучше, чем XML, по следующим причинам:

  • API для чтения / записи намного (намного) проще.
    • Получение значений так же просто, как чтение ключей из словаря.
  • Это менее многословно, более легко читаемо простыми смертными.
    • Это также означает, что для анализа огромных данных требуется меньше места и меньше времени.
0 голосов
/ 28 октября 2009

Он более компактен, чем XML, и в некоторых случаях быстрее анализируется. Поэтому я обычно предпочитаю это.

С другой стороны, XML действительно решает несколько проблем спецификаций, предлагая решения (например, кодировки).

Однако я могу просто написать в своей спецификации «Вы должны использовать только UTF-8», и тогда проблема со спецификациями кодирования будет решена.

По сути, JSON можно использовать, если вам нужна простая структура ключ / значение или вложенная структура ключ / значение / список, и вы хотите, чтобы общие проблемы с выходом и разделением решались за вас, с большим количеством доступных анализаторов.

Я написал по крайней мере один протокол с использованием JSON, и пользователи его никогда не жаловались на использование JSON вместо XML, несмотря на то, что работали в Microsoft.NET:)

0 голосов
/ 26 октября 2009

IMO, если вы собираетесь сохранить вещи и хотите иметь возможность обновить приложение (что практически всегда так), вам следует создать свой код сериализации вручную и создать документированный формат файла. В противном случае у вас возникнут большие проблемы в какой-то момент.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...