Корневые узлы в JSON

Question

Мне поручено определить связь между двумя веб-приложениями. Я решил использовать JSON для этого. Как часто встречается корневой узел в JSON?

Допустим, у нас есть автомобильный объект. Это JSON с корневым узлом "Car":

{"Car": { 
  "Make":"Mustang", 
  "YearBuilt":"1999"}}

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

{"Tire": {"Make": "Brirdgestone", "Size":"15"}}

Интеграция объекта шины JSON в оригинальный объект Car показывает, насколько громоздким он может быть.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999",
"Tires": "[{"Tire": {"Make": "Brirdgestone", "Size":"15"}},
{"Tire": {"Make": "Brirdgestone", "Size":"15"}},
{"Tire": {"Make": "Bridgestone", "Size":"15"}},
{"Tire": {"Make": "Brirdgestone", "Size":"15"}}
]}}

Таким образом, сериализованная в PHP, модель первого Tire будет $object->Car->Tires[0]->Tire->Make Там есть дополнительный уровень шины из-за корневого узла.

Если бы у Tire не было корневого узла, код мог бы быть намного тоньше.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999",
"Tires": "[{ {"Make": "Bridgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}}]}}

В PHP меньше путаницы, потому что меньше избыточности: марку первой шины называют $object->Car->Tires[0]->Make

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

Answer 1

Я бы пропустил оба корневых узла: Шина и Автомобиль .

Имейте в виду, что основное использование JSON - это передача объектов по сети в компактном формате.,Там нет никакого реального использования помимо этого.Вы хотите работать с данными, которые кодирует JSON, и, добавляя корневые узлы, вы создаете пустые контейнерные объекты без реальной идентичности и цели.Опуская корневые узлы, вы получите

$car->tires[0]->make

, а в JS вы получите

car.tires[0].make

Это намного понятнее и представляет объект гораздо лучше.Помните, с этим вам придется работать.Конечно, вы могли бы использовать какой-то JSON mapper, который отображает, как объекты должны быть сериализованы и которые приводят к вышеперечисленным объектам, но это много дополнительных усилий и не стоит их imho.

Если вы хотите иметьимя класса в JSON, просто сделайте его свойством, например

{ 'klass': 'Car', 'make': 'Mustang', 'year':1999 }

Answer 2

@ Гордон делает хорошие очки. Однако мне нравится использовать AOP с сообщениями AJAX для перехвата сообщений на сервер и с сервера. Эти перехватчики добавляют к каждому сообщению метку времени, а в сообщениях, отправляемых с сервера, флаг состояния (сбой, исключение, успех, что угодно ...). Как вы, вероятно, догадались, я использовал корневой узел JSON для полезной нагрузки, статуса и метки времени.

Флаг состояния, отправленный с сервера, может быть проверен в одной функции (аспекте) внешнего интерфейса, а все исключения обработаны в одном месте. Когда происходит сбой сервера по причине, отличной от исключения, аспект / рекомендация позволяет передавать данные инициатору AJAX.