Ответ 1
Предположим, что вы говорите об использовании JSON в сравнении с пользовательским форматом (с использованием типа MIME text/plain) для передачи структурированных данных.
Производительность может быть разбита на разные компоненты; например.
- относительное время, затрачиваемое на кодирование содержимого в формате,
- относительное время, затраченное на декодирование формата, чтобы предоставить исходный контент, и
- относительный размер кодированного содержимого.
В теории можно сказать, что гипотетический оптимально спроектированный и реализованный пользовательский формат будет не медленнее или не менее плотным, чем JSON. ( "Доказательство" очевидно. Выберите оптимальную реализацию JSON и внесите некоторые незначительные изменения в формат, который не влияет на производительность.)
В действительности, однако, вам нужно сравнить производительность фактических форматов и фактических реализаций. Поэтому ответ на этот вопрос зависит от того, насколько хорошо вы работаете над проектированием и внедрением формата и связанного с ним программного обеспечения для кодирования/декодирования. Кроме того, это также зависит от того, как вы реализуете JSON. Существует несколько серверных JSON-библиотек с различными характеристиками производительности, а также различные способы отображения данных из/в "родные" структуры данных.
Это подводит нас к реальным преимуществам JSON (и XML) в пользовательских форматах.
-
С JSON и XML доступны библиотеки для любого основного языка, который вы выбрали для помощи в кодировании и декодировании контента. С пользовательским форматом вам нужно перевернуть свою собственную кодировку/декодирование для сторон клиента и сервера.
-
В JSON и XML есть стандарты, которые говорят, что хорошо сформировано, что позволяет другим людям внедрять кодировщики/декодеры. В специальном формате вы должны сами написать спецификацию, если хотите, чтобы другие люди могли реализовать ваш формат.
-
JSON и XML имеют стандартные способы решения таких проблем, как кодировка кодировки и символы "мета", появляющиеся в данных. С обычаем вы должны понимать и решать эти проблемы самостоятельно. (И если вы этого не сделаете, вы, вероятно, столкнетесь с трудностями на пути.)
-
Простота изменения. Это относительно простой вопрос для разработки формата JSON/XML. Но с пользовательским форматом у вас есть (по крайней мере) больше работы, и в зависимости от ваших вариантов дизайна это может быть очень сложно.
Для большинства приложений эти проблемы имеют значение гораздо больше, чем производительность. И именно поэтому широко используются JSON или XML.
Followup
Но что, если вместо этого вы предполагаете, что я не использую собственную реализацию и сравниваю отправку JSON с типом mime text/plain с типом application/json?
Тогда ответ заключается в том, что он отличается от почти не.
- Вы сохраняете 6 байтов в заголовке запроса HTTP или ответа, потому что строка типа mime короче, но это не имеет значения для типичных HTTP-сообщений, размеры которых измеряются в тысячах байтов.
- Использование типа содержимого "text/plain" не имеет никакого отношения к работе, которая должна быть выполнена для кодирования/декодирования сообщений запроса или ответа... кроме времени, затраченного на сравнение/копирование 6 дополнительных байтов, что вероятно, слишком мал для измерения.
Кроме того, использование неточного MIME-типа (возможно) является нарушением спецификаций HTTP. Если вы это сделаете:
-
более вероятно, что получатель будет неправильно реагировать; например не удалось его декодировать или показать в окне браузера, а
-
вы можете нарушить согласование типа содержимого HTTP, считая, что ваш клиент или сервер его использует.
Короче говоря, я не могу придумать никаких веских оснований для этого и несколько веских причин не делать этого.