Почему встраивание JSON в XML плохое?

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

<root>
 <stuff>
  thing
 </stuff>
 <more>
  <[!CDATA[{"a":["b","c"]}]]>
 </more>
</root>

и просто поместить его в xml

<root>
 <stuff>
  thing
 </stuff>
 <more>
  <a>
   b
  </a>
  <a>
   c
  </a>
 </more>
</root>

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

Изменяется ли ваш ответ, если у нас есть существующая конечная точка, которая анализирует ответ JSON? Нам пришлось бы перекодировать эту конечную точку для проглатывания XML.

Ответ 1

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

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

Наконец, вы не сможете легко делать то, что смотрит на всю структуру сразу. Например, вы не можете использовать XPath для захвата битов JSON и не можете обрабатывать весь ответ как объект JavaScript. Смешивая два формата, вы получаете проблему "худшего из двух миров", когда дело доходит до манипулирования данными.

Ответ 2

Это похоже на обсуждение нормализации базы данных. Это чище и элегантнее делать все в чистом XML (или нормализовать схему базы данных), таким образом, вы не обязательно связаны с вашей конкретной реализацией. Но если вам нужно затем преобразовать XML в объекты JavaScript (или присоединиться к 5 таблицам для каждого проклятого SELECT), вы можете написать много дополнительного кода и понести ненужные хиты производительности.

Все зависит от того, как вы уравновешиваете удобство с формальной корректностью. Если это формат обмена XML, который будет стандартизован W3C и использоваться миллионами, тогда дорогой Бог, не используйте JSON. Если это для собственного приложения, которое будет обрабатываться только кодом, который вы сами написали, тогда вверните его, просто бросьте JSON туда и двигайтесь дальше!

Ответ 3

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

Ответ 4

Это не по своей сути неправильно. Если у вас есть причина для этого, и альтернативы хуже, то вам следует это сделать. Как всегда, решение должно оцениваться в контексте, в котором оно работает (проклятые академики).

В моем случае у меня есть глобальная база данных с RESTful JSON API, регламент ЕС, который гласит, что я должен создать локальную копию, к которой можно получить доступ к данным, если глобальная база данных недоступна, и инфраструктура, построенная на SOAP и XML.

Нам нужно всего пять полей из ста полевой записи JSON для повседневных операций. Так что нет, я не собираюсь делать вид, что пуризм приводит к хорошим решениям, и вводить совершенно новый стандарт в нашу инфраструктуру API. Я собираюсь извлечь несколько полей, которые мне нужны, и вернуть остальные в виде JSON, обернутого в раздел CDATA.

Конечно, наши клиентские приложения не используют парсеры XML, поэтому для них не требуется использовать два парсера. Они используют структуры SOAP, которые выполняют их анализ.

Ответ 5

Во-первых, я понимаю, что отправляю сообщения через 8 лет после того, как был задан этот вопрос, но я обещаю, что у меня есть веская причина для этого.

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

Связь с внешней системой ДОЛЖНА использовать SOAP.
Связь SOAP ДОЛЖНА быть описана файлом WSDL.
Наша система должна принять и скомпилировать файл WSDL для использования, который генерирует набор скомпилированных классов и методов Java.
Если WSDL обновляется, наша система должна перекомпилировать WSDL, для чего необходимо выполнить ПОЛНЫЙ процесс изменения, который может занять месяцы.
"Их система", которая должна получать данные SOAP от нас, разрабатывается и поддерживается совершенно отдельной командой, и существуют различные барьеры, мешающие двум группам фактически сотрудничать. (По сути, у нас есть один шанс бросить что-то через стену, что они могут использовать и расширять по мере необходимости; любой возврат туда и обратно задержит проект на месяцы).
Ни один из вышеперечисленных факторов не может быть изменен или подвергнут сомнению.

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