JSON Toolbox: почему JSON оказался удобен для веб-API

JSON часто описывают как формат, который победил XML благодаря отсутствию закрывающих тегов. Такая версия хорошо помещается в один абзац, но плохо объясняет историю: XML создавался прежде всего как универсальная разметка для документов и обмена структурированной информацией, тогда как JSON вырос из практической задачи передачи состояния между браузером и сервером. Для простого веб-API модель JSON действительно оказалась удобнее, однако это не делает XML ошибкой и не означает, что оба формата решают одну и ту же задачу одинаковым способом.

Зачем создавали XML

К середине 1990-х HTML уже доказал, что документы удобно передавать по сети, но его фиксированного набора тегов не хватало издательским, научным и отраслевым системам. SGML позволял создавать собственные языки разметки, однако был слишком сложен для массового использования в вебе. Рабочая группа W3C взяла его основные идеи и подготовила более компактный набор правил, который 10 февраля 1998 года стал рекомендацией XML 1.0.

XML позволял автору определить подходящие элементы и сохранить не только дерево данных, но и структуру документа. Например, внутри абзаца можно чередовать текст с выделениями, ссылками и формулами, не раскладывая содержимое на искусственный набор полей. Атрибуты описывали свойства элементов, порядок дочерних узлов сохранялся, а комментарии и инструкции обработки входили в сам синтаксис.

В простом случае XML не требовал всего семейства дополнительных стандартов. Пространства имён понадобились, когда в одном документе стали смешивать несколько словарей и нужно было различать одноимённые элементы; W3C закрепил этот механизм в январе 1999 года. XSLT решал отдельную задачу преобразования XML-дерева в другой документ, а выпущенный в 2001 году XML Schema позволял описать допустимую структуру, ограничения и типы вроде даты или целого числа. Эти технологии усложняли экосистему, но появлялись не ради форматирования одного объекта, а для повторного использования словарей, проверки документов и автоматизации сложного обмена.

Цена такой универсальности заметна даже в небольшом примере:

<person>
  <name>Alex</name>
  <age>30</age>
</person>

Без XML Schema парсер видит содержимое age как текст, зато формат позволяет без смены модели добавлять атрибуты, смешанный контент и элементы из других пространств имён. Для документа это полезно, но объекту приложения часто нужна гораздо более узкая модель.

Как появился JSON

В 2001 году Дуглас Крокфорд и Чип Морнингстар создавали в State Software платформу для приложений, которые сегодня назвали бы одностраничными. Браузер должен был обмениваться с сервером небольшими порциями состояния без полной перезагрузки страницы, и команде требовалось представление, которое одинаково легко собиралось на сервере и превращалось в объект в JavaScript.

Подходящий синтаксис уже находился в самом языке: объектные и массивные литералы выражали именно те структуры, которыми оперировало приложение. Крокфорд позднее подчёркивал, что не считает себя первым изобретателем такого приёма; по его собственному рассказу, несколько разработчиков приходили к нему независимо. Его вклад состоял в том, что весной 2001 года он применил эту модель в State Software, назвал её JavaScript Object Notation, а в 2002 году приобрёл домен json.org и опубликовал описание формата. Морнингстар участвовал в проектировании серверной системы и исходной задачи обмена, но спецификацию и последующий RFC писал Крокфорд.

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

{
  "name": "Alex",
  "age": 30
}

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

Стандарт появился после практики

В июле 2006 года RFC 4627 зарегистрировал медиатип application/json и формально описал синтаксис, который уже применялся в реальных системах. Единственным автором документа был Дуглас Крокфорд. Первая редакция считала верхним уровнем только объект или массив, а позднейшие спецификации разрешили любое значение JSON и уточнили требования совместимости.

Сегодня основной документ IETF, RFC 8259, датирован декабрём 2017 года и согласован с ECMA-404. Он определяет JSON как языково-независимый текстовый формат и требует UTF-8 при обмене между системами. Поэтому называть RFC 4627 окончательной современной спецификацией уже неправильно, хотя именно он был важным этапом стандартизации.

Ранние браузерные приложения иногда разбирали полученную строку через eval(), поскольку корректный JSON был близок к выражению JavaScript. Удобство сопровождалось серьёзным риском: eval() выполняет код с правами страницы, поэтому недоверенный ответ мог превратиться в XSS. В декабре 2009 года стандарт ECMAScript 5 добавил отдельные JSON.parse() и JSON.stringify(), после чего необходимость исполнять входные данные исчезла. Современный код должен использовать JSON-парсер, а не eval().

Почему JSON подошёл веб-API

Главное преимущество JSON заключалось не в абстрактной простоте, а в удачном совпадении моделей. Состояние интерфейса, параметры запроса и ответы большинства API естественно представляются объектами, массивами, строками, числами, логическими значениями и null. Аналогичные структуры есть в словарях Python, массивах PHP, map и struct в Go, коллекциях Java и множестве других языков, поэтому формат быстро перестал зависеть от JavaScript.

Для таких сообщений JSON обычно требует меньше служебного синтаксиса, чем парные XML-теги, а небольшой набор правил облегчает реализацию парсера. Но универсальной процентной экономии не существует: результат зависит от структуры, имён полей, использования XML-атрибутов и сжатия на транспортном уровне. На больших однотипных массивах ключи JSON тоже повторяются, а бинарные форматы могут быть существенно компактнее обоих вариантов.

Минимализм создаёт и ограничения. JSON не различает целые и дробные числа, не имеет встроенных дат и двоичных данных, не поддерживает смешанный документный контент, пространства имён и ссылки между объектами. Схему можно описать отдельным стандартом JSON Schema, но она не является частью базовой грамматики. Кроме того, разные реализации могут по-разному обрабатывать повторяющиеся имена полей и числа, выходящие за точный диапазон конкретного языка.

XML остаётся сильнее там, где документ одновременно предназначен для чтения, разметки и машинной обработки, где в одном файле нужно сочетать несколько словарей или где давно существует строгая схема отраслевого обмена. JSON удобнее для объектоподобных сообщений веб-приложения и большинства небольших API. Выбор определяется формой данных и требованиями к ним, а не итогом воображаемой войны форматов.

Что умеет JSON Toolbox

JSON Toolbox проверяет ввод через браузерный JSON-парсер сразу по мере набора. Если движок сообщает позицию синтаксической ошибки, инструмент переводит её в строку и колонку, отмечает соответствующую строку в gutter и показывает сообщение во всплывающей подсказке.

После успешного разбора доступны три представления: подсвеченный Formatted с отступами в два или четыре пробела либо табуляцией, сворачиваемое дерево с типами значений и Minified в одну строку. Выбранный размер отступа сохраняется для других форматирующих инструментов сайта. Рядом выводятся число ключей и строк, суммарное количество символов в ключах и строковых значениях, а также размеры форматированной и минимизированной версий в байтах. Представления Formatted и Minified можно скопировать; разбор выполняется локально, и вставленные данные не отправляются на сервер.

Чтобы быстро проверить работу, вставьте {"users":[{"id":1,"name":"Alex"},{"id":2,"name":"Maria"}]}, переключитесь между Formatted, Tree и Minified, затем удалите запятую между полями. Валидатор отметит ошибочную строку, а после возврата запятой снова построит все три представления.

Похожие инструменты

JSON ToolboxПроверяйте синтаксис, форматируйте или минифицируйте данные и просматривайте вложенные API-ответы и конфиги в виде дерева.Конвертер YAML, JSON, TOML и .envКонвертируйте между YAML, JSON, TOML, .env и shell-экспортом с автоопределением входного формата, настраиваемым отступом и явным предупреждением там, где целевой формат не умеет что-то выразить — null в TOML, вложенность в .env.API и веб-песочницаПревращайте команды cURL в код на JavaScript, Python, PHP или Go, либо открывайте живое WebSocket-соединение и наблюдайте за сообщениями — прямо в браузере.SQL FormatterФорматируйте SQL с ключевыми словами на новой строке и настраиваемым отступом или минифицируйте в одну строку — с учётом диалекта MySQL, PostgreSQL и SQLite.