> Какой формат данных выбрать для клиента: JSON, YAML или XML и почему (JavaScript, Go)

Короткий ответ

Для клиента в большинстве случаев выбирайте JSON. Он нативно поддерживается JavaScript, имеет минимальный overhead при парсинге и сериализации, хорошо типизирован для Go. YAML уместен только для конфигурационных файлов, XML - для legacy-систем или строгих схем валидации. JSON обеспечивает лучший balance между читаемостью, производительностью и совместимостью.

Подробное объяснение

Выбор формата данных для клиента зависит от контекста использования, но JSON является де-факто стандартом для REST API и веб-клиентов.

JSON:

• Нативная поддержка в JavaScript (JSON.parse/JSON.stringify) без дополнительных библиотек
• Минимальный размер payload по сравнению с XML (отсутствие closing tags)
• Высокая скорость парсинга в Go (encoding/json, а также более быстрые alternatives вроде json-iterator)
• Простая структура, легко читаемая человеком
• Хорошая поддержка в большинстве языков и фреймворков

YAML:

• Более читаемый для человека, особенно для конфигураций (отступы вместо скобок)
• Поддерживает комментарии (важно для конфигов)
• Медленнее парсится, чем JSON
• Сложнее в обработке на клиенте (требует библиотек)
• Потенциальные проблемы с безопасностью (десериализация может быть опасной)

XML:

• Строгая валидация через XSD схемы
• Поддержка namespaces и атрибутов
• Избыточный размер из-за closing tags
• Сложный парсинг на клиенте (DOM/SAX парсеры)
• Используется в SOAP, legacy-системах, некоторых конфигах

Для клиента на JavaScript JSON - очевидный выбор из-за нативной поддержки. Для Go JSON также предпочтителен благодаря эффективной сериализации и широкой поддержке.

На практике

Для REST API используйте JSON с content-type application/json. Если клиент - браузерное приложение, JSON обеспечивает минимальную задержку. Для конфигурационных файлов (например, docker-compose, CI/CD) YAML более уместен. XML стоит применять только если клиент legacy или требуется строгая схема валидации с XSD.

Trade-off: JSON не поддерживает комментарии, что может быть минусом для конфигов. YAML сложнее в парсинге и может вызывать ошибки из-за отступов. XML избыточен для современных клиентов.

Пример кода

JAVASCRIPT
// JavaScript client - JSON is native
const data = { name: "test", value: 42 };
const json = JSON.stringify(data); // {"name":"test","value":42}
const parsed = JSON.parse(json);

// Go server - JSON is efficient
type Data struct {
    Name  string `json:"name"`
    Value int    `json:"value"`
}
var d Data
json.Unmarshal([]byte(`{"name":"test","value":42}`), &d)

Как отвечать на собеседовании

Начните с прямого ответа: JSON для клиента. Обоснуйте производительностью и нативной поддержкой в JavaScript/Go. Упомяните исключения (YAML для конфигов, XML для legacy). Приведите конкретные примеры из опыта. Покажите понимание trade-off: размер, скорость парсинга, читаемость. Не углубляйтесь в детали реализации, если не спросят.

Что проверяет интервьюер

• Понимание различий форматов данных
• Умение выбирать инструмент под задачу
• Знание особенностей JavaScript и Go
• Опыт работы с реальными проектами
• Понимание trade-off между производительностью и удобством

Типичные ошибки

• Выбор YAML для API из-за "читаемости" без учёта производительности
• Использование XML для нового проекта без legacy-причин
• Игнорирование нативной поддержки JSON в JavaScript
• Предложение использовать Protobuf или другие бинарные форматы без учёта контекста клиента
• Неучёт безопасности (YAML десериализация может быть опасной)