Почему встраивание 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.