JSON

JSON, или JavaScript Object Notation, — это текстовый формат представления структурированных данных. Он используется для передачи информации между приложениями, хранения настроек, обмена данными через API и интеграции различных информационных систем.

JSON представляет информацию в виде объектов, массивов и простых значений. Формат легко читается человеком и поддерживается практически всеми современными языками программирования.

Например, Backend может вернуть Frontend данные пользователя в JSON, а браузер преобразует их в объект и отображает имя, email и другие поля в интерфейсе.

Что такое JSON простыми словами

JSON можно представить как стандартизированный способ записать данные в текстовом виде так, чтобы их одинаково понимали разные программы.

Например, вместо передачи строки Иван, 125, active сервер может явно указать название каждого свойства.

{
 "id": 125,
 "name": "Иван",
 "active": true
}

Так клиент понимает, что 125 — идентификатор пользователя, Иван — имя, а true обозначает активный статус.

JSON описывает данные и их структуру, но сам по себе не определяет бизнес-логику обработки этих данных.

Для чего нужен JSON

JSON используется практически на всех уровнях современной разработки.

• передача данных через REST API;
• обмен между Frontend и Backend;
• Webhook-события;
• конфигурационные файлы;
• хранение структурированных настроек;
• логирование;
• интеграция сервисов;
• работа мобильных приложений;
• обмен данными между микросервисами;
• экспорт и импорт информации.

Как выглядит JSON

JSON состоит из пар ключ-значение, объединенных в объекты, и последовательностей значений, объединенных в массивы.

{
 "order_id": 501,
 "status": "paid",
 "total": 4500,
 "items": [
 {"product_id": 10, "quantity": 2},
 {"product_id": 18, "quantity": 1}
 ]
}

В этом примере объект содержит номер заказа, статус, сумму и массив товаров.

Какие типы данных есть в JSON

JSON поддерживает ограниченный набор базовых типов.

Что такое JSON Object

Object — набор пар ключ-значение, заключенный в фигурные скобки.

{
 "name": "Иван",
 "age": 35,
 "verified": true
}

Ключи объекта являются строками. Значениями могут быть строки, числа, Boolean, null, массивы или другие объекты.

Что такое JSON Array

Array — упорядоченный список значений, заключенный в квадратные скобки.

["Москва", "Казань", "Новосибирск"]

Массив может содержать и сложные объекты.

[
 {"id": 1, "name": "Товар A"},
 {"id": 2, "name": "Товар B"}
]

Такой формат часто используется API для возврата списков пользователей, заказов или других сущностей.

Строки в JSON

Строковые значения и ключи JSON записываются в двойных кавычках.

{"city": "Москва"}

Одинарные кавычки не являются стандартной заменой двойных кавычек в JSON.

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

Числа в JSON

Числа записываются без кавычек.

{"price": 1990.50, "quantity": 3}

Если записать значение как “1990.50”, оно станет строкой, а не числом.

Это важно для вычислений, сортировки и валидации данных.

Boolean в JSON

Логические значения записываются как true и false без кавычек.

{"available": true}

Строка “true” является обычным текстом и отличается от логического значения true.

Что означает null

null обозначает отсутствие конкретного значения.

{"middle_name": null}

При этом null не всегда означает то же самое, что полностью отсутствующее поле.

Например, API может трактовать отсутствие поля как не изменять значение, а null — как явно удалить его. Семантика должна быть определена контрактом API.

Вложенный JSON

Объекты и массивы можно вкладывать друг в друга.

{
 "user": {
 "id": 125,
 "name": "Иван",
 "contacts": {
 "email": "user@example.com"
 }
 }
}

Благодаря вложенности JSON подходит для описания достаточно сложных структур данных.

JSON и JavaScript

Название JSON происходит от JavaScript Object Notation, а синтаксис действительно похож на JavaScript-объекты.

Однако JSON является самостоятельным форматом обмена данными и используется не только в JavaScript.

Python, Java, C#, Go, PHP и практически все современные языки имеют библиотеки для чтения и формирования JSON.

JSON и объект JavaScript

Сериализация JSON

Сериализация — преобразование объекта программы в текст JSON.

Например, Backend имеет объект заказа в памяти. Перед отправкой клиенту его нужно преобразовать в последовательность символов.

После сериализации JSON передается по сети или сохраняется в файл.

Десериализация JSON

Десериализация — обратный процесс.

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

Например, JavaScript превращает JSON в объект, а Python — в словари, списки и примитивные значения.

JSON и API

JSON является одним из самых распространенных форматов передачи данных в HTTP API.

Клиент может отправить JSON при создании объекта.

{
 "product_id": 42,
 "quantity": 2
}

Backend обрабатывает запрос и возвращает собственный JSON-ответ.

{
 "order_id": 501,
 "status": "created"
}

JSON и REST API

REST не требует обязательного использования JSON, но на практике эта комбинация встречается очень часто.

REST определяет архитектурный подход к взаимодействию с ресурсами, а JSON используется как формат представления данных.

Поэтому понятия REST и JSON нельзя считать синонимами.

Content-Type application/json

При передаче JSON по HTTP сервер или клиент обычно сообщает формат содержимого через заголовок Content-Type.

Content-Type: application/json

Это позволяет принимающей стороне понять, как интерпретировать тело сообщения.

Неправильный Content-Type может привести к тому, что Backend не распознает запрос как JSON.

JSON и Frontend

Frontend постоянно работает с JSON при взаимодействии с Backend.

Например, браузер отправляет API-запрос и получает список товаров.

JavaScript преобразует JSON в объект, после чего интерфейс создает карточки товаров.

Пользователь при этом не видит сам JSON — он видит готовый интерфейс.

JSON и Backend

Backend формирует JSON-ответы и принимает JSON-запросы.

Но перед обработкой сервер обязан валидировать данные.

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

Например, поле quantity может содержать число -100. JSON остается валидным, но заказ с отрицательным количеством товара должен быть отклонен.

JSON и Fullstack

Fullstack-разработчик работает с JSON сразу на обеих сторонах приложения.

Backend формирует структуру ответа, Frontend читает ее и отображает данные.

Если одна сторона изменяет название или тип поля без согласования, приложение может перестать работать.

Поэтому структура JSON является частью API Contract.

JSON и Webhook

Webhook-события часто передаются в JSON.

Например, платежный сервис отправляет тип события, идентификатор платежа и его статус.

{
 "event": "payment.succeeded",
 "payment_id": "pay_125",
 "status": "paid"
}

Получатель должен проверить подпись Webhook, а затем валидировать JSON Payload.

JSON и GraphQL

GraphQL-запрос имеет собственный синтаксис, но результат выполнения обычно представляется в JSON-подобной структуре данных.

Клиент выбирает поля в Query, а сервер возвращает соответствующую структуру.

Таким образом, GraphQL и JSON также решают разные задачи: GraphQL определяет способ запроса, а JSON может использоваться для представления результата.

JSON и gRPC

gRPC обычно использует Protocol Buffers и бинарную сериализацию вместо JSON.

Это делает сообщения более компактными и позволяет использовать строгие .proto-контракты.

JSON при этом проще читать человеку и удобен для многих публичных HTTP API.

JSON и XML

JSON и XML используются для передачи структурированных данных.

JSON обычно имеет более компактный синтаксис и естественно работает с объектами и массивами.

XML имеет собственную модель документов, атрибуты, namespaces и развитые механизмы схем.

JSON и YAML

JSON и YAML часто используются для конфигураций.

YAML обычно более удобен для ручного редактирования благодаря меньшему количеству скобок и кавычек.

JSON имеет более строгий и простой синтаксис для машинной обработки.

Например, Kubernetes и Docker Compose часто используют YAML, а многие приложения сохраняют пользовательские настройки в JSON.

JSON как конфигурационный файл

Приложение может хранить настройки в JSON-файле.

{
 "host": "127.0.0.1",
 "port": 8080,
 "debug": false
}

Такой файл легко прочитать программно.

Однако пароли и API-ключи не следует автоматически хранить в обычном JSON-файле, особенно если он попадает в Git.

JSON и секреты

JSON не обеспечивает шифрование или защиту информации.

Если в файл записать пароль, он останется обычным читаемым текстом.

Для чувствительной информации необходимы подходящие системы Secret Management и контроль доступа.

JSON — это формат данных, а не механизм безопасности.

JSON Schema

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

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

Например, можно указать, что поле email обязательно, age должно быть числом, а status может принимать только определенные значения.

Это полезно для API, конфигураций и автоматической валидации.

Зачем нужна JSON Schema

Без схемы две программы могут по-разному интерпретировать одинаковую структуру.

Один клиент ожидает price как число, а сервер неожиданно начинает возвращать строку.

Формальное описание помогает обнаруживать такие несовместимости до production.

JSON и OpenAPI

OpenAPI позволяет описывать HTTP API, включая JSON-запросы и ответы.

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

Это помогает Frontend и Backend согласовать структуру данных и генерировать часть документации или клиентского кода.

Валидация JSON

Проверка JSON происходит на нескольких уровнях.

1. Проверяется синтаксис JSON.
2. Проверяется структура относительно Schema или модели.
3. Проверяются типы значений.
4. Применяются бизнес-правила.

Например, документ может быть синтаксически корректным, но содержать неизвестный product_id. Такая ошибка обнаруживается уже на уровне бизнес-логики.

Что такое валидный JSON

Валидный JSON соответствует правилам синтаксиса формата.

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

{"name":"Иван","active":true}

Следующая запись JSON не является корректной из-за отсутствия кавычек вокруг ключа.

{name:"Иван"}

Типичные синтаксические ошибки JSON

• одинарные кавычки вместо двойных;
• пропущенная запятая;
• лишняя запятая в конце;
• незакрытая фигурная или квадратная скобка;
• ключ объекта без двойных кавычек;
• неэкранированная кавычка внутри строки;
• использование неподдерживаемого значения.

Экранирование символов

Некоторые символы внутри JSON-строки необходимо экранировать.

Например, двойную кавычку внутри текста нужно отличить от кавычки, завершающей строку.

{"message":"Пользователь нажал кнопку "Сохранить""}

Также существуют escape-последовательности для перевода строки, табуляции и некоторых других символов.

Unicode в JSON

JSON поддерживает Unicode, поэтому может содержать русский текст, китайские иероглифы и другие символы.

{"city":"Санкт-Петербург"}

При передаче данных важно, чтобы все компоненты системы согласованно работали с кодировкой.

В современных веб-системах обычно используется UTF-8.

Комментарии в JSON

Стандартный JSON не предусматривает обычные комментарии, знакомые по языкам программирования.

Поэтому запись с // или другими комментариями может не пройти стандартный JSON Parser.

Если комментарии нужны в конфигурации, применяют другой формат или отдельное поле описания.

Дата и время в JSON

JSON не имеет отдельного встроенного типа Date.

Дата обычно передается как строка по согласованному формату.

{"created_at":"2026-08-17T12:00:00Z"}

Клиент и сервер должны заранее договориться о формате и timezone, иначе возможны ошибки при обработке времени.

Денежные значения в JSON

Финансовые данные требуют отдельной осторожности.

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

Поэтому денежные суммы иногда передаются как целое количество минимальных денежных единиц или как строка с формально определенным decimal-значением.

Конкретная модель должна быть частью API-контракта.

Большие числа в JSON

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

Например, очень большой идентификатор способен корректно существовать на Backend, но потерять точность после преобразования в определенный числовой тип Frontend.

Поэтому большие идентификаторы нередко передаются строками.

JSON и null

При проектировании API необходимо четко определить различие между null, пустой строкой, нулем и отсутствующим полем.

Все четыре состояния могут иметь разный бизнес-смысл.

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

JSON и логирование

Structured Logging часто использует JSON.

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

{
 "level": "ERROR",
 "service": "payment-api",
 "request_id": "abc-125",
 "message": "Payment failed"
}

Такие журналы удобнее фильтровать и анализировать автоматически.

JSON и ELK Stack

Структурированные JSON-логи удобно передавать в системы централизованного логирования.

Elasticsearch может индексировать отдельные поля, после чего инженер ищет события по service, level или Request ID.

Это значительно удобнее разбора произвольных текстовых строк.

JSON и NoSQL

Некоторые документные базы работают с моделями данных, похожими на JSON.

Документ может содержать вложенные объекты и массивы без классической структуры реляционной таблицы.

Однако формат хранения конкретной СУБД не обязательно буквально совпадает с текстовым JSON.

JSON является представлением данных, а NoSQL — более широкая категория баз данных.

JSON в SQL-базах

Современные реляционные СУБД также могут поддерживать хранение JSON-структур в отдельных типах колонок.

Это полезно для части гибких атрибутов, но не означает, что всю реляционную модель следует помещать в одно JSON-поле.

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

JSON и микросервисы

Микросервисы могут взаимодействовать через HTTP API с JSON.

Например, order-service отправляет payment-service данные платежа.

Преимущество JSON заключается в простоте и независимости от языка программирования.

Для очень частых внутренних вызовов иногда используют gRPC и Protocol Buffers.

JSON и Message Queue

Сообщения в очередях также могут содержать JSON.

Например, событие OrderCreated передает идентификатор заказа, пользователя и сумму.

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

JSON и Event-driven Architecture

В событийной архитектуре JSON часто используется как Payload события.

Но имя события, версия схемы и семантика полей должны быть определены не менее строго, чем для обычного API.

Иначе изменение одного производителя может сломать множество потребителей.

JSON и Git

JSON-файлы можно хранить в Git как обычный текст.

Это удобно для конфигураций и небольших наборов структурированных данных.

Однако автоматически генерируемый JSON с постоянным изменением порядка полей может создавать неудобные diff.

Для секретов Git использовать не следует.

JSON и CI/CD

Pipeline может генерировать, читать и проверять JSON.

Например, тест сохраняет результаты в JSON, а следующий этап анализирует их.

CI также может валидировать конфигурационные файлы по JSON Schema до deployment.

JSON и Docker

Docker-инструменты и приложения внутри контейнеров могут использовать JSON для конфигураций и обмена данными.

При этом Docker Compose обычно описывается через YAML, поскольку он удобнее для ручного редактирования многострочных конфигураций.

Выбор формата зависит от задачи.

JSON и Kubernetes

Kubernetes API работает со структурированными объектами, которые могут представляться в JSON, хотя пользователи часто пишут манифесты в YAML.

YAML-конфигурация преобразуется в структурированное представление, с которым работает API.

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

JSON и Terraform

Terraform обычно использует HCL, поскольку этот язык удобнее для описания Infrastructure as Code.

Но JSON может встречаться при работе с внешними API, Policy, автоматически генерируемыми данными и интеграциями.

Инженеру полезно понимать преобразование между структурами Terraform и JSON.

JSON и безопасность

JSON сам по себе не является опасным форматом, но данные из него нельзя автоматически считать безопасными.

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

• ограничивать размер Payload;
• валидировать типы;
• проверять обязательные поля;
• не доверять клиентским значениям;
• не хранить секреты в открытом JSON;
• контролировать глубину вложенности;
• не выполнять полученные строки как код.

JSON Injection

Ошибки могут возникать, если JSON формируется ручной конкатенацией строк без корректного экранирования.

Безопаснее использовать стандартный Serializer языка программирования.

Он правильно обработает кавычки, специальные символы и типы данных.

Тот же принцип применяется и при разборе входных данных: следует использовать надежный JSON Parser, а не самописный разбор строк.

JSON и производительность

JSON удобен, но текстовое представление обычно занимает больше места, чем специализированные бинарные форматы.

Кроме того, данные нужно сериализовать и разобрать на принимающей стороне.

Для большинства обычных веб-API эти расходы приемлемы.

В высоконагруженных межсервисных системах иногда выбирают Protocol Buffers или другие бинарные форматы.

Большие JSON-документы

Если API возвращает огромный JSON на сотни мегабайт, проблема может быть не только в формате, но и в дизайне интерфейса.

Большие списки следует разделять через Pagination, а файлы передавать специализированными механизмами.

Так уменьшается потребление памяти и время ожидания.

Минификация JSON

Пробелы и переносы строк обычно не влияют на смысл JSON.

Для передачи по сети формат можно записать компактно.

{"id":125,"name":"Иван","active":true}

Для разработки и документации часто используют форматирование с отступами, поскольку оно удобнее для чтения человеком.

Pretty Print

Pretty Print — форматирование JSON с переносами строк и отступами.

Оно не меняет структуру данных, но облегчает чтение и отладку.

В production API форматирование обычно не является обязательным и лишь увеличивает размер ответа.

Порядок полей JSON

Клиент не должен строить бизнес-логику на предположении, что поля объекта всегда будут передаваться в конкретном порядке.

Объект следует обрабатывать по именам ключей.

Если порядок элементов имеет бизнес-значение, для этого используется Array.

Дублирующиеся ключи

Не следует создавать JSON-объекты с одинаковым ключом несколько раз.

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

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

Типичные ошибки при работе с JSON

1. Использовать одинарные кавычки.
2. Добавлять лишнюю запятую после последнего поля.
3. Передавать число как строку без причины.
4. Не различать null и отсутствующее поле.
5. Вручную собирать JSON через конкатенацию строк.
6. Не валидировать данные после Parsing.
7. Хранить секреты в JSON-файле внутри Git.
8. Возвращать огромные массивы без Pagination.
9. Менять структуру API без согласования.
10. Считать синтаксически корректный JSON автоматически безопасным.

Как правильно проектировать JSON API

Шаг 1. Определить понятные названия полей

Названия должны отражать смысл данных и использовать единый стиль во всем API.

Шаг 2. Зафиксировать типы

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

Шаг 3. Определить правила null

Необходимо описать разницу между отсутствующим и пустым значением.

Шаг 4. Ограничить размер списков

Для больших коллекций следует использовать Pagination.

Шаг 5. Создать Schema или API Contract

Это позволяет автоматически проверять структуры и уменьшать количество ошибок интеграции.

Шаг 6. Валидировать входные данные

Parsing JSON — только первый этап проверки.

Шаг 7. Контролировать совместимость

Изменение существующих полей может нарушить работу старых клиентов.

Практический пример

Интернет-магазин имеет Frontend и Backend. Пользователь открывает страницу заказа.

Frontend отправляет запрос GET /api/orders/501.

Backend находит заказ в базе данных и сериализует его в JSON.

{
 "id": 501,
 "status": "paid",
 "total": 4500,
 "items": [
 {"id": 10, "name": "Товар A", "quantity": 2}
 ]
}

Браузер получает ответ, разбирает JSON и показывает пользователю статус, сумму и товары.

Если пользователь меняет адрес доставки, Frontend отправляет новый JSON на Backend.

Сервер сначала проверяет синтаксис и структуру, затем права пользователя и бизнес-правила. Только после этого изменение записывается в базу.

Структура запросов и ответов описана в OpenAPI, поэтому Frontend и Backend используют согласованный контракт.

JSON для бизнеса

JSON сам по себе является техническим форматом, но его распространенность значительно упрощает интеграцию информационных систем.

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

Для бизнеса это означает более простое подключение новых сервисов и автоматизацию процессов.

Основной риск связан не с JSON как форматом, а с плохо спроектированными контрактами, отсутствием валидации и несовместимыми изменениями.

Когда использовать JSON

• создается REST API;
• Frontend обменивается данными с Backend;
• нужна простая межсистемная интеграция;
• передаются Webhook-события;
• создается структурированный лог;
• нужен небольшой конфигурационный файл;
• важна поддержка большого количества языков программирования;
• данные должны быть относительно легко читаемы человеком.

Когда JSON может быть не лучшим вариантом

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

Для сложных ручных конфигураций YAML иногда удобнее благодаря менее шумному синтаксису.

Для документов со сложной структурой, namespaces и существующими корпоративными стандартами может использоваться XML.

Формат следует выбирать исходя из конкретного сценария, а не только популярности.

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

Краткий итог

JSON — текстовый формат представления структурированных данных. Он поддерживает объекты, массивы, строки, числа, Boolean и null и широко используется в веб-разработке, API, Webhooks, конфигурациях и логировании.

Главными преимуществами JSON являются простой синтаксис, читаемость и поддержка практически всеми современными языками программирования. Благодаря этому он стал одним из основных форматов взаимодействия Frontend и Backend.

При работе с JSON важно отличать синтаксическую корректность от корректности самих данных. Backend должен валидировать типы, бизнес-правила и права пользователя, а структура API — иметь понятный контракт. Для высокопроизводительных или специализированных сценариев вместо JSON могут использоваться Protocol Buffers, XML, YAML и другие форматы.