Создание ответов JSON еще меньше... просто идея

Просто мысль действительно... и задается вопросом, охватывает ли Gzipped JSON это.

Но скажите, что у вас есть список игровых объектов в ответе:

game = {
    name: 'Randomer Quest!',
    description: 'Randomer Quest is a brilliant game!',
    activated: true,
    points: 10,
    thumb: 'randomer-quest.jpg'
};

Когда вы json_encode это, он становится 151 bytes:

{"games": [{"name":"Randomer Quest!","description":"Randomer Quest is a brilliant game!","activated":true,"points":10,"thumb":"randomer-quest.jpg"}]}

Хорошо... но что, если у вас есть список из примерно 100 игр? Что о 13,913 bytes... но действительно ли нам нужно объявлять эти свойства? Я знаю, что вы можете просто декодировать его и пропустить его (волшебство), но что, если мы немного умнее об этом и объявим свойства в отдельном объекте, а затем будем иметь массив данных? Мы должны были предварительно заполнить свойства, которых обычно нет, но я все еще думаю, что это того стоит.

Что-то вроде этого:

{
"games": {
    p: ["name", "description", "activated", "points", "thumb"],
    d: [
        ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
        ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
    ]
}

}

P - свойства, D - данные в массивах. Впоследствии мы имеем: 9,377 bytes 67% от размера!

Хорошо, я знаю, вы скажете, что ничего, кроме вас, видят запросы, которые больше похожи на 40-100kb. И я думаю, что это довольно большая разница. Кто-нибудь уже использует что-то подобное? Возможно, у нас есть инструменты, которые уже делают это автоматически?

32bitkid в значительной степени сказал, что если вы собираетесь это сделать, вы можете просто обрезать его до формата CSV... что имеет смысл... это будет около 9,253 bytes 66,5%.

"name", "description", "activated", "points", "thumb"
"Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"
"Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"

Я видел запросы JSON около 100 кб, которые превратились бы в 66.5kb (потерять 33.5kb)

Как вы думаете?

Дом

ОТВЕТЫ

Ответ 1

Я согласен, что это гораздо более компактно.

{
    "games": {
        p: ["name", "description", "activated", "points", "thumb"],
        d: [
            ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
            ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
        ]
    }
}

Но подождите, вы можете оптимизировать его дальше, вам действительно нужен объект "игр"? это еще меньше!

{
    p: ["name", "description", "activated", "points", "thumb"],
    d: [
        ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
        ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
    ]
}

И действительно, в чем смысл "p" и "d" и содержащегося в нем объекта, я знаю, что имена свойств будут первыми, а мои данные будут вторыми?

[
    ["name", "description", "activated", "points", "thumb"],
    ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
    ["Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
]

И эти маркеры объектов и объектов просто мешают, сохраняют еще несколько байтов!

"name", "description", "activated", "points", "thumb"
"Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"
"Randomer Quest!", "Randomer Quest is a brilliant game!", true, 10, "randomer-quest.jpg"

Подождите... этот формат уже существует. Это CSV. И это было вокруг с середины 1960-х. И его часть причины, почему XML и JSON были изобретены в первую очередь. JSON и XML добавляют гибкость хранящимся объектам и делают их более удобными для чтения, чем плотно упакованные двоичные объекты. Вы действительно обеспокоены размером данных, проходящих по трубе? Если вы (если это, по сути, ваше узкое место), то существует множество способов решения этой проблемы.

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

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

Найдите шаблон, который решает вашу проблему, а не наоборот.

Ответ 2

Из опыта, основной причиной использования текстовых форматов является то, что они легки для человека (с неискушенными инструментами) для чтения и отладки. [Например, я считаю XML огромным бездействием для большинства задач].

Довольно старая ссылка о том, почему мы используем текстовые форматы, хотя по-прежнему стоит серьезное чтение, в этой главе "Искусство программирования Unix" .

Итак, вы должны стремиться к ясности, а не к размеру. Стремление к размеру - это преждевременная оптимизация.

Если вас беспокоит пропускная способность или хранилище, подумайте об сжатии данных. Текстовые форматы хорошо подходят для быстрого и мощного сжатия, до тех пор, пока технически они не уступают бинарным форматам. Кроме того, вы разделяете проблемы 1/представляете данные удобно 2/эффективно передаете данные.

Я не осведомлен в этом домене, но я готов поспорить, что есть 1/Javascript-библиотеки для сжатия 2/систематические способы сжатия данных на уровне протокола.

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

Ответ 3

Я использую ColdFusion для серверного языка, который имеет функцию serializeJson(). Это создает пакет JSON, и если он из запроса, он выглядит почти так же, как то, что вы предлагаете.

{
    "COLUMNS": [
        "ID",
        "NAME"
    ],
    "DATA": [
        [
            1,
            "London"
        ],
        [
            2,
            "Liverpool"
        ],
        [
            3,
            "Glasgow"
        ]
    ]
}

Хорошо работает тоже.

Ответ 4

Это довольно интересно, вы можете проверить BSON, если у вас есть много данных для передачи.

Ответ 5

Как насчет MessagePack?

http://msgpack.org/

MessagePack - эффективный формат двоичной сериализации. Это позволяет вам обмен данными между несколькими языками, такими как JSON. Но это быстрее и меньше. Малые целые числа кодируются в один байт, а типичные короткие строки требуют только одного дополнительного байта в дополнение к строкам сами по себе.

Ответ 6

На самом деле да, вы можете. 30 лет назад процессор был не таким, как сегодня, поэтому нет смысла сжимать json и распаковывать его на стороне клиента.

Что я мог сделать, это:

  • Заменить весь экземпляр "," ----------> |//с 3 байтов на 1
  • Заменить весь экземпляр },{ ----------> ^//с 3 байтов на 1
  • Заменить весь экземпляр :" ----------> *//с 3 байтов на 1

А из json 100k у вас будет 50k Json, а на стороне клиента вы замените эти символы обратно, а затем у вас будет все это.

Вы можете пойти глубже, если, например, вы скажете, что я заменю все "abd" ----> @ или, возможно, слова, которые существуют слишком много раз, на один символ, который никогда не находится внутри json.