Преимущества использования application / json по сравнению с text / plain? [closed]

Предположим, что вы говорите об использовании 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 и MIME type application / json?

Тогда ответ таков: практически не имеет разницы в и производительности .

• Вы сохраняете 6 байтов в заголовке HTTP-запроса или ответа, потому что строка типа mime короче, но это несущественно для типичных сообщений HTTP, размеры которых измеряются тысячами байтов.
• Использование типа контента «текст / обычный» не имеет значения для работы, которую необходимо выполнить для кодирования / декодирования сообщений запроса или ответа ... кроме времени, необходимого для сравнения / копирования 6 дополнительных байтов, что вероятно, слишком мал, чтобы измерить.

Кроме того, использование неточного MIME-типа является (возможно) нарушением спецификации HTTP. Если вы сделаете это:

• , более вероятно, что получатель неправильно обработает ответ; например не удается декодировать его или показать в окне браузера, и

• вы можете прервать согласование типа содержимого HTTP, предполагая, что ваш клиент или сервер использует его.

Короче говоря, я не могу придумать веских причин для этого и нескольких причин не делать этого.