Бинарные форматы обмена данными

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору

JSON и YAML удобны людям и отладке. В высоконагруженных каналах (микросервисы, мобильные клиенты, очереди) часто выбирают бинарные форматы: меньше байт, быстрее парсинг, явная схема.

Текстовые форматы: JSON, YAML. Использование в API: интеграции.

---

Сравнение

Формат	Схема	Читаемость	Размер	Типичное применение
JSON	Нет (опционально JSON Schema)	Высокая	Базовый	Публичные REST API
MessagePack	Нет	Низкая	Меньше JSON	Кэш, внутренние очереди
BSON	Нет	Низкая	Компактнее JSON	MongoDB на диске
Protocol Buffers	.proto, строгая	Низкая	Очень компактно	gRPC, внутренние контракты
CBOR	Опционально	Низкая	Компактно	IoT, COSE/JWT-подобные сценарии

---

MessagePack

«Бинарный JSON»: те же типы (map, array, int, str), но без повторения имён полей в каждом сообщении.

Когда: внутренний кэш (Redis), сериализация сессии, когда обе стороны на одном стеке и не нужна эволюция схемы годами.

Осторожно: без схемы легко сломать совместимость при смене типа поля.

---

BSON

Расширение JSON с типами даты, ObjectId, бинарными полями. Нативен для MongoDB.

Когда: документная БД, вложенные структуры, GridFS.

Не обязан быть форматом API наружу — наружу часто всё равно JSON.

---

Protocol Buffers (Protobuf)

Схема в .proto → кодогенерация классов → бинарный wire-format.

Плюсы:

• компактность и скорость;
• явная версионность полей (optional, reserved);
• основа gRPC.

Минусы:

• нужен пайплайн codegen;
• неудобно читать в DevTools без декодера.

Когда: service-to-service, стриминг, жёсткий контракт между командами.

Минимальный .proto и идея wire-format:

syntax = "proto3";

message Order {
  string order_id = 1;
  double amount = 2;
  string currency = 3;
}

Поле = 1 — номер в бинарном потоке (не порядок в тексте). При эволюции API старые поля помечают reserved, новые добавляют с новыми номерами.

---

CBOR (Concise Binary Object Representation)

CBOR (RFC 8949) — бинарный формат, близкий по модели данных к JSON: map, array, текст, числа, байты, логические значения. Часто используют там, где нужна компактность, но не хочется схему Protobuf: IoT, встраиваемые устройства, некоторые криптографические обёртки (рядом с COSE).

Аспект	CBOR	MessagePack	Protobuf
Схема	Опционально (CDDL)	Нет	Обязательна .proto
Самоописание	Теги типов в потоке	Аналогично	Только по .proto
Типичный размер	Меньше JSON	Сопоставимо	Обычно меньше всех

Тот же смысл, что JSON {"theme":"dark","port":8080}, в CBOR кодируется короче за счёт бинарных ключей и чисел; в hex-дампе файл нечитаем без декодера — как у Protobuf.

Когда выбирать CBOR: ограниченный канал, парсер на устройстве, контракт «как JSON», но без текстового тела. Когда не нужен: публичный REST для браузера — остаётся JSON.

---

Выбор для архитектора

Правила:

1. Публичный API — JSON (или JSON + опциональный binary content-type).
2. Не десериализуйте бинарь из ненадёжного источника без валидации длины и схемы.
3. Версионируйте контракт (semver API, поля v2 в Protobuf).
4. Логи и трассировка — оставляйте текст (JSON-логи), не Protobuf.

---

Безопасность

Бинарные форматы не «безопаснее» JSON. Уязвимости в парсерах и неограниченная вложенность возможны везде. Ограничивайте размер тела запроса на reverse proxy.

---

Связанные темы

• gRPC в обзоре API
• Компетенции бэкенда

---