Есть ли какой-либо известный метод DRYing JSON

Рассмотрим этот ответ JSON:

[{
    Name: 'Saeed',
    Age: 31
}, {
    Name: 'Maysam',
    Age: 32
}, {
    Name: 'Mehdi',
    Age: 27
}]

Это отлично подходит для небольшого объема данных, но если вы хотите обслуживать большие объемы данных (скажем, много тысяч записей, например), представляется логичным предотвращать повторения имен свойств в ответе JSON.

Я изучил концепцию (DRYing JSON) и, к моему удивлению, я не нашел никакого релевантного результата. Один из способов, конечно, состоит в том, чтобы сжать JSON с помощью простого домашнего алгоритма и распаковать его на стороне клиента, прежде чем его использовать:

[['Name', 'Age'], 
['Saeed', 31], 
['Maysam', 32], 
['Mehdi', 27]]

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

Ответ 1

Одно из решений известно как алгоритм hpack

https://github.com/WebReflection/json.hpack/wiki

Ответ 2

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

Если имена свойств и формат ответа сервера уже известны коду, вы можете просто вернуть данные в виде массива переменных значений:

['Saeed', 31, 'Maysam', 32, 'Mehdi', 27]

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

"Saeed, 31, Maysam, 32, Mehdi, 27"

или если вы все еще хотите, чтобы он был действительным JSON, вы можете поместить эту строку в массив вроде этого, который немного лучше, чем моя первая версия, где сами элементы являются элементами массива:

["Saeed, 31, Maysam, 32, Mehdi, 27"]

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

Ответ 3

Возможно, вы сможете использовать формат CSV вместо JSON, так как вы только укажете имена свойств один раз. Однако для этого потребуется жесткая структура, как в вашем примере.

JSON на самом деле не тот, который поддается DRY, поскольку он уже довольно хорошо упакован, учитывая то, что вы можете с ним сделать. Лично я использовал голые массивы для данных JSON, которые хранятся в файле для последующего использования, но для простых запросов AJAX я просто оставляю его как есть.

DRY обычно ссылается на то, что вы пишете сами, поэтому, если ваш объект генерируется динамически, вы все равно не должны беспокоиться об этом.

Ответ 4

Использовать gzip-сжатие, которое обычно легко встроено в большинство веб-серверов и клиентов?

По-прежнему потребуется некоторое (дополнительное) время и память для генерации и анализа JSON на каждом конце, но не потребуется много времени для отправки по сети и будет предпринимать минимальные усилия по осуществлению от вашего имени.

Возможно, стоит сделать снимок, даже если вы предварительно скомпилируете исходные данные.

Ответ 5

На самом деле для JSON не проблема, что у вас часто бывает массивная строка или дублирование свойств (а также не для XML).

Это именно то, что дублировать устранение строки компонент адресов DEFLATE-алгоритмов (используется GZip).

В то время как большинство клиентов браузера могут принимать GZip-сжатые ответы, трафик на сервер не будет.

Это гарантирует использование "сжатия JSON" (т.е. hpack или какой-либо другой схемы)?

Это вряд ли будет намного быстрее, чем реализация GZip-сжатия в Javascript (что не невозможно: на достаточно быстрой машине вы можете сжать 100 КБ в 250 мс).
Очень сложно безопасно обрабатывать ненадежный вход JSON. Вам нужно использовать синтаксический анализ на основе потоков и определить максимальный порог сложности, иначе ваш сервер может оказаться неожиданным. См. Например, Armin Ronacher Начать писать дополнительные классы:

Если ваш аккуратный маленький веб-сервер получает 10000 запросов в секунду через gevent, но использует json.loads, то я, вероятно, могу заставить его заходить на полпути, отправив ему 16 МБ хорошо продуманного и вложенного JSON, изгоняющего весь ваш процессор.