XML не мёртв (к сожалению) — преобразуйте его в JSON как взрослый

Вы изучили REST. Вы приняли JSON. Вы думали, что эра XML закончилась, как Flash или IE6 — что вы будете рассказывать молодым разработчикам, как сказку на костре. А затем ваш новый клиент передал вам учетные данные для интеграции с банковской системой, и вот оно — 400-страничный SOAP-обертка, смотрящий на вас прямо в глаза.

Добро пожаловать обратно в XML. Оно никогда не уходило.

Почему XML всё ещё повсюду

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

• SOAP-услуги – По-прежнему стандарт для финансовых учреждений, страховых платформ и крупных ERP-систем. Ваша интеграция в fintech, вероятно, проходит через одну из них.
• Банковские API – ISO 20022, сообщения SWIFT и многие основные банковские API передают данные в формате XML. Вариант REST отсутствует.
• Государственные данные – HMRC, IRS и большинство правительственных порталов принимают или возвращают данные в формате XML. Это не изменится скоро.
• Корпоративные среды интеграции – SAP, Oracle и устаревшие системы ESB работают с XML по умолчанию. Если вы интегрируетесь с чем-то корпоративным, скорее всего, столкнётесь с XML.
• RSS и Atom-фиды – Всё ещё XML. Многие системы обработки контента, новостные агрегаторы и инструменты мониторинга зависят от них.

Неприятная правда: XML не исчезает, потому что системы, построенные на нём, не исчезают. Замена ядра банка — это не задача на короткий срок. Поэтому вы адаптируетесь.

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

Перед тем как начать конвертировать, полезно понять, почему конвертация XML в JSON — это не просто замена формата. Два формата моделируют данные по-разному, и эти различия создают реальные трудности.

Сравнение: одинаковые данные в обоих форматах

Рассмотрим простой заказ клиента. Вот он в XML:

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

И вот его эквивалент в JSON:

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Уже можно увидеть структурные проблемы. Давайте их рассмотрим.

Атрибуты против ключей

Элементы XML могут содержать атрибуты (id="ORD-1042") вместе с дочерними элементами и текстовым содержимым. JSON не имеет понятия атрибутов — всё это ключ-значение. Наиболее распространённая конвенция — префиксировать атрибуты символом @ при конвертации, что даёт вам "@id": "ORD-1042". Некоторые парсеры используют $ или полностью разворачивают их. Конвенция важна, потому что ваша потребительская кодировка должна знать, какой префикс ожидать.

Массивы против повторяющихся элементов

Это постоянно вводит разработчиков в заблуждение. В JSON массив — это явный элемент: [...]. В XML нет такого различия — повторяющиеся сопутствующие элементы по умолчанию являются списком. Парсер, который видит один <item> элемент, может вернуть объект. Два <item> элемента? Он возвращает массив. Ваша кодировка ломается, когда API возвращает один результат.

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

Текстовые узлы и смешанный контент

Элементы XML могут содержать как текстовое содержимое, так и дочерние элементы одновременно (смешанный контент). JSON не может это чётко представить. Парсеры обрабатывают это по-разному — некоторые используют ключ #text , другие используют _, другие просто отбрасывают смешанный контент. Если вы конвертируете XML с смешанным контентом, проверьте результат вручную.

Пространства имен

Ответы SOAP полны XML-пространств имен: <ns2:getOrderResponse xmlns:ns2="http://...">. В зависимости от вашего парсера, они либо удаляются, либо сжимаются в имя ключа (ns2:getOrderResponse), либо отображаются как URI. Чаще всего вы хотите их удалять, но если два пространства имен имеют одинаковое имя элемента, вы потеряете различие. Знайте, что вы имеете, прежде чем предполагать, что выход чистый.

Быстрый путь: конвертировать XML онлайн без написания парсера

Если вы отладываете ответ API, изучаете неизвестную схему XML или выполняете одноразовую конвертацию, написание парсера — излишне. Используйте Конвертер XML в JSON — вставьте свой XML, получите чистый JSON и проверьте структуру перед написанием кода.

Оно обрабатывает атрибуты (с конвенцией префикса @ ), вложенные элементы, повторяющиеся элементы как массивы и сохраняет текстовое содержимое — что покрывает большинство реальных API-пакетов. Полезно для быстрого понимания того, как выглядит ответ SOAP после того, как оболочка убрана до данных.

Программная конвертация: что использовать в производстве

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

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser — лучший выбор для Node.js. Используйте isArray для принудительного обработки массивов для известных элементов списка — это предотвращает несоответствие между одним элементом и массивом, которое в конечном итоге повлияет на производственные системы.

Питон

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict — стандартный выбор для Python. Оно использует конвенцию @ для атрибутов и #text для текстовых узлов. Обратите внимание, что оно возвращает объект OrderedDict, который сериализуется без проблем с json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

PHP’s simplexml_load_string + json_encode — быстрый путь, но обрабатывает атрибуты непостоянно и может потерять данные в крайних случаях. Для производственной работы с ответами SOAP, рассмотрите DOMDocument с LIBXML_NOBLANKS или специальную библиотеку.

Общие трудности, на которые стоит обратить внимание

• Числа выводятся как строки. XML не имеет числового типа — всё это текст. Ваше поле цены будет "49.99", а не 49.99. Неявно преобразуйте после конвертации.
• Логические значения остаются строками. <active>true</active> превращается в "active": "true". Проверяйте перед использованием в условиях.
• Пустые элементы становятся null или пустыми объектами. <middleName/> может конвертироваться в null, "", или {} в зависимости от парсера. Проверьте крайний случай.
• Секции CDATA могут быть сохранены или нет. Если API использует CDATA для экранирования HTML-контента, проверьте, как ваш парсер обрабатывает это и не удаляет содержимое без ведома.
• Порядок не гарантируется. Порядок элементов в XML может быть значимым в некоторых схемах; порядок ключей в JSON не является значимым. Если последовательность важна для потребителя, обработайте это явно.

Работа с SOAP в частности

SOAP добавляет ещё один уровень на XML: каждый ответ обернут в <Envelope> с <Body>, часто с декларациями пространств имен и блоком <Header> . Перед конвертацией в JSON, обычно нужно извлечь только содержимое тела.

В Python с zeep (клиент SOAP), вы получаете Python-объекты напрямую и не нужно парсить XML самостоятельно. В Node.js, soap и strong-soap делайте то же самое. Если вы обращаетесь к SOAP-эндпоинту напрямую с fetch или axios, вам нужно вручную убрать оболочку перед запуском конвертера XML в JSON.

Для быстрого просмотра ответов SOAP, полезен Конвертер XML в JSON — вставьте полную оболочку, увидите полную структуру и определите, какой путь к данным вам действительно нужно.

Принимайте реальность и двигайтесь дальше

Существует определённый вид боли, возникающий при осознании того, что ваш проект на начальном этапе должен интегрироваться с API на SOAP, созданным в 2003 году. Позвольте себе почувствовать это, а затем двигайтесь дальше. XML — решённая проблема — парсеры зрелы, инструменты конвертации существуют, и трудности хорошо документированы. Вы не первый раз, кто смотрит на 400-страничную оболочку.

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

И для экспериментальной работы — понимание неизвестной схемы XML, проверка конвертации перед написанием кода — сохраните Конвертер XML в JSON в закладках. Это быстрее, чем запускать скрипт каждый раз, когда вам нужно просмотреть пакет.

Вам также может понравиться