Размер JSON ответа API: формула и калькулятор

Размер JSON в байтах = sum(длина_ключа_в_UTF8 + длина_значения_в_UTF8) + overhead. Overhead включает:

• кавычки вокруг ключей и строковых значений — 2 байта на каждый ключ и каждое строковое значение;
• двоеточие между ключом и значением — 1 байт;
• запятые между элементами — 1 байт на разделитель;
• фигурные/квадратные скобки — для объекта/массива 2 байта (откр + закр).

Для чисел и bool кавычки не нужны, overhead меньше. В UTF-8 кириллические символы занимают 2 байта, латиница и цифры — 1 байт. Пример: ключ "name" (4 латинских) = 4 байта, значение "Сергей" (6 кириллических) = 12 байт. С overhead: кавычки (2+2=4), двоеточие (1), итого 4+12+4+1 = 21 байт.

Допустим, API возвращает массив из 10 пользователей с полями: id, name, email, age. Каждое поле:

• id (число, 4 разряда) — 4 байта, overhead нет;
• name (строка, средняя русская — 10 букв) — 20 байт (UTF-8), + 2 кавычки, +1 двоеточие = 23;
• email (строка, в среднем 20 латинских) — 20 байт, +3 = 23;
• age (число, 2 цифры) — 2 байта, overhead 1 (двоеточие) = 3.

Сумма на один объект: скобки {} = 2, запятые между полями (3 шт.) = 3, итого: 4+23+23+3 + 2 + 3 = 58 байт. Массив из 10 объектов: скобки [] = 2, запятые между объектами (9) = 9, итого 10*58 + 2 + 9 = 591 байт. С отступами (pretty print) добавится ~20% пробелов. Реальный ответ ~800 байт.

• Путаница между string и number: строка '0' весит 3 байта (0 + 2 кавычки), число 0 — 1 байт.
• Неучтённые пробелы и табуляции: в production почти всегда minified, но после сериализации могут добавиться.
• Подсчёт длины в символах, а не байтах: кириллица — 2 байта на символ, эмодзи — 4 байта.
• Забывают про overhead массивов: каждый открывающий/закрывающий символ — 1 байт.

Используйте Калькулятор размера JSON ответа API — он учтёт все нюансы.

1. Сокращайте ключи: "user_name" → "un", "first_name" → "fn". Если клиент известен — используйте маппинг.
2. Не форматируйте: отключите pretty print в production, экономия ~20%.
3. Используйте массивы вместо объектов: если поля всегда одинаковы, массив значений экономит ключи.
4. Удаляйте null и пустые строки: не отправляйте поля с null — клиент может использовать default.
5. Выбирайте правильный тип данных: дату лучше передавать Unix timestamp (число) вместо ISO-строки.

После оптимизации проверяйте утилитами или калькулятором размера JSON.

Кроме калькулятора, полезны конвертеры для подготовки тестовых данных:

• CSV в JSON — быстро перевести табличные данные в JSON для API.
• JSON в CSV — экспорт ответа для анализа в Excel.
• JSON в XLSX — если нужен формат .xlsx напрямую.
• XLSX в JSON — подготовить данные из Excel для API.

• Лимиты облачных функций: AWS Lambda возвращает до 6 МБ, GCP Cloud Functions — до 10 МБ. Превышение = ошибка 413.
• Мобильный трафик: 1 МБ в роуминге может стоить $10. Каждый килобайт на счету.
• Время TTFB: при скорости 1 Мбит/с (сельская местность) передача 500 КБ занимает ~4 секунды.
• Парсинг на клиенте: большой JSON тормозит UI, особенно на старых устройствах.

Всегда сжимайте ответ gzip — это уменьшает размер в 5-10 раз. Но помните, что размер в байтах до сжатия важен для лимитов API и расчёта трафика.

1. Получите реальный ответ от API (через curl или Postman).
2. Проверьте длину в байтах: curl -s -o /dev/null -w '%{size_download}' https://api.example.com/data.
3. Сравните с расчётным размером через калькулятор.
4. Проанализируйте структуру: используйте jsonlint.com для визуализации.
5. Примените оптимизации из раздела выше, повторите замер.

Если размер превышает ожидаемый, ищите дублирование данных или необязательные поля.

• Версионируйте эндпоинты: /v1/users — чтобы можно было ломать формат без ущерба.
• Используйте код состояния 206 Partial Content для частичных ответов (Range).
• Пагинация обязательна: возвращайте первые 50-100 записей и ссылки на следующие.
• Избегайте глубокой вложенности: больше 3 уровней усложняет парсинг и увеличивает размер.
• Стандартизируйте ошибки: единый формат {code, message, details}.

Соблюдение этих правил упрощает жизнь и вам, и клиентам.