Спросите двух инженеров travel-tech, каким должен быть фид инвентаря - XML или JSON, - и вы получите тридцатиминутный спор. Честный ответ: для инвентаря туров и трансферов работают оба варианта, и формат редко определяет, будет ли интеграция успешной или провальной. Гораздо важнее контракт - схема, стабильность и то, как обрабатываются изменения. Тем не менее у выбора есть реальные компромиссы, которые стоит понимать.
Где XML всё ещё оправдывает себя
- Схемы и валидация. XSD позволяет проверить фид по формальной схеме до обработки - это ценно для каталожных данных со строгими правилами.
- Отраслевой прецедент. Значительная часть туристической дистрибуции (обмен сообщениями в стиле OTA/NDC) исторически основана на XML, поэтому инструменты и ожидания уже существуют.
- Атрибуты и пространства имён. Для записей с богатой структурой атрибуты позволяют сохранять документы компактными и самоописывающими.
<product code="hagia-sophia-grand-bazaar" type="tour"> <title>Hagia Sophia & Grand Bazaar Tour</title> <duration>PT8H</duration> <net currency="EUR">149.50</net> </product>
Где выигрывает JSON
- Удобство для разработчиков. Он напрямую отображается на нативные объекты почти в любом языке - меньше формальностей, быстрее парсинг.
- Размер полезной нагрузки. Меньше накладных расходов на разметку, что важно для больших или часто запрашиваемых фидов.
- Инструменты для современного веба. Если ваш стек - это JavaScript/TypeScript или JSON-ориентированный API-шлюз, JSON устраняет лишний шаг преобразования.
{ "code": "hagia-sophia-grand-bazaar", "type": "tour",
"title": "Hagia Sophia & Grand Bazaar Tour",
"duration": "PT8H", "net": 149.50, "currency": "EUR" }
Выбирайте формат, на котором ваш стек уже свободно говорит. Цена борьбы с собственными инструментами перевешивает любую абстрактную элегантность.
То, что действительно имеет значение
Какой бы формат вы ни выбрали, настаивайте на следующем:
- Документированная, версионируемая схема. Вы должны иметь возможность проверить полезную нагрузку и знать, когда грядёт ломающее изменение.
- Стабильные идентификаторы. Коды продуктов не должны меняться при редактировании названия.
- Явные единицы измерения. Длительность в формате ISO 8601 (
PT8H), деньги с явно указанной валютой, время с часовым поясом. - Чёткий сигнал "удалено". Чтобы отсутствующий продукт означал "снят с продажи", а не "обрезанный файл".
Прагматичная рекомендация
Если вы начинаете с нуля и работаете в JSON-нативной среде, выбирайте JSON. Если у вас уже работает дистрибуция на основе XML или вам нужна формальная валидация по схеме, XML вполне надёжен. Ещё лучше - работать с поставщиком, который может предоставить каталог в предпочитаемом вами формате и сохранять одни и те же идентификаторы продуктов в обоих, - так формат становится деталью реализации, а не привязкой к поставщику. Именно так Connect предоставляет инвентарь туров и трансферов по Стамбулу: один стабильный контракт и представление, которое подходит вашей команде.