Интеграция через API, файлы или промежуточную базу: что выбрать

Как понять, какой способ обмена данными между системами подходит именно вам

Единого «правильного» способа интеграции не существует — выбор зависит от того, что умеют обе системы, насколько срочно данные должны попадать из одной в другую и кто отвечает за их поддержку. API подходит, когда нужен обмен близко к реальному времени и обе стороны готовы поддерживать интерфейс. Файловый обмен — рабочий вариант для периодической выгрузки больших объёмов данных и для систем без публичного API, но не годится для мгновенной синхронизации. Промежуточная база данных (или интеграционная шина/очередь сообщений) нужна, когда систем много, а связывать их «каждая с каждой» становится слишком дорого и хрупко. На практике в одном проекте нередко сочетаются два-три подхода: например, заказы уходят через API в реальном времени, а прайс-листы поставщиков обновляются раз в сутки файлом.

В чём вообще проблема

Компания редко живёт с одной информационной системой. Сайт или интернет-магазин, CRM, склад, бухгалтерия на 1С, служба доставки, банк, ЭДО — у каждой системы свои данные, и рано или поздно их приходится связывать между собой: чтобы заказ с сайта попадал в CRM, остатки со склада отражались в каталоге, а платежи из банка закрывали счета в бухгалтерии.

Проблема в том, что «интеграция» — это не одна технология, а несколько принципиально разных архитектурных решений, и ошибка на этом этапе стоит дорого: неподходящий способ обмена потом сложно поменять, не остановив бизнес-процессы. Эта статья — для тех, кто выбирает архитектуру обмена данными между двумя и более системами и хочет понимать, чем один вариант отличается от другого не на уровне лозунгов, а на уровне практических последствий.

Три базовых способа простыми словами

Технологии интеграции информационных систем в основе своей сводятся к нескольким моделям: вызов API (или удалённый вызов процедур), обмен сообщениями через брокер и файловый обмен, при котором система-источник кладёт файлы на сервер, а система-приёмник их забирает; отдельно стоит вариант с общей базой данных, к которой обращаются сразу несколько систем [1]. Разберём три подхода, которые встречаются чаще всего.

API — «прямой разговор» между системами

API задаёт контракт, по которому одна система получает данные или запускает действие в другой. Обмен может быть синхронным, когда ответ нужен в рамках запроса, и асинхронным — через задачу, webhook, поток событий или последующую проверку статуса. Поэтому архитектуру выбирают не по слову «API», а по требованиям к задержке, подтверждению результата и безопасному повтору.

Если у обеих систем есть документированный API, интеграция сводится к тому, чтобы связать их «переводчиком», который понимает форматы данных и правила обеих сторон.

Плюсы:

• данные передаются практически сразу, без задержек, характерных для периодических выгрузок;
• меньше ручных операций и связанных с ними ошибок — в заказах, платежах, остатках [3];
• один и тот же API можно подключать к разным системам, что упрощает добавление новых сервисов в инфраструктуру.

Минусы и ограничения:

• задержки возможны при большом числе последовательных запросов для сложных операций, а сбои сети или изменения на стороне сервера способны нарушить работу интеграции [6];
• при синхронном взаимодействии клиент и сервер вынуждены заранее договориться о формате и структуре запросов и ответов, из-за чего одна система становится зависимой от изменений в другой [6];
• наличие технической возможности подключиться к API ещё не означает, что доступ открыт всем желающим — отдельно нужно выяснять, требуется ли регистрация, договор, тестовая среда и какие операции вообще доступны, а для некоторых государственных систем — ещё и усиленная квалифицированная электронная подпись организации.

Файловый обмен — «оставил файл, забрал файл»

При файловом обмене система-источник формирует файл (XML, CSV, JSON, DBF и другие форматы) и кладёт его в согласованное место — на файловый сервер, в папку по FTP/SFTP или в облачное хранилище, а система-приёмник в своё время эти файлы забирает и обрабатывает [1].

Классический пример в российской практике — обмен между 1С и интернет-магазином по стандарту CommerceML: 1С формирует файлы import.xml (справочники и товары) и offers.xml (цены и остатки), которые сайт периодически считывает и загружает к себе [5].

Когда файловый обмен уместен:

• нет доступа к API одной из систем, зато есть возможность выгрузить данные в файл;
• объём данных большой, а требования к скорости — умеренные (например, ночная выгрузка каталога товаров);
• системы разных поколений или разных производителей, у которых нет общего протокола, кроме файла.

Ограничения:

• файловый обмен принципиально не подходит для передачи данных в реальном времени [1];
• нужно отдельно продумывать обработку ошибок — что делать, если файл повреждён, пришёл не полностью или в устаревшем формате;
• при передаче файлов между организациями стоит использовать защищённые протоколы: обычный FTP передаёт логин, пароль и сами данные в открытом виде, тогда как SFTP шифрует и данные, и служебные команды сессии [14].

Промежуточная база данных, очередь сообщений и интеграционная шина

Третий подход — не связывать системы напрямую, а завести посредника. Это может быть:

• общая (интеграционная) база данных, куда одна система пишет, а другая читает данные;
• очередь сообщений (message broker) — например, RabbitMQ или Kafka, где отправитель кладёт сообщение в очередь, а получатель забирает его в своём темпе;
• интеграционная шина (ESB) — специализированное middleware, которое принимает данные от нескольких систем, приводит их к единому формату, маршрутизирует и следит за доставкой [9].

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

Когда стоит выбирать посредника, а не связи «точка-точка»:

• систем много (условно, больше 4–5), и связывать их попарно через API станет неуправляемо — количество связей растёт быстрее, чем количество самих систем;
• нужна асинхронность: отправитель не должен ждать, пока получатель обработает данные, а сообщения не должны теряться, даже если получатель временно недоступен — очередь хранит, подтверждает и при необходимости повторяет доставку [12];
• система станет высоконагруженной или потребует потоковой обработки данных, а не разовых пакетов — тогда рассматривают инструменты класса Apache Kafka, Apache NiFi или Apache Airflow [18].

Если задача — просто передать данные из системы A в систему B без сложной трансформации и маршрутизации, полноценная ESB, скорее всего, избыточна: с этим справится более лёгкое решение — прямая интеграция или ETL-инструмент [9]. Отдельная шина также не нужна, если компания использует облачные SaaS-решения одного вендора, у которых уже есть встроенные механизмы интеграции [9].

Как эти подходы соотносятся друг с другом на практике

Синхронные HTTP-вызовы не всегда проще или надёжнее асинхронного обмена сообщениями, а очереди сообщений не всегда оправданы там, где цель — просто снизить связанность систем: выбор зависит от конкретной задачи, а не от того, какой подход выглядит современнее [13]. Разработчики сравнивают эти способы по нескольким осям: направление взаимодействия, сложность реализации, безопасность, объём данных, пропускная способность, задержка, простота внедрения и доступность готовых инструментов, — и REST, очереди сообщений, вебхуки, gRPC и другие варианты попадают в разные места этой матрицы, а не выстраиваются в единый рейтинг «лучше — хуже» [8].

Практический вывод: сравнивать стоит не абстрактно «API против файлов», а конкретную задачу — объём данных, требуемую скорость, число систем-участников и то, что из этого умеют делать сами системы.

Российская специфика

1С и обмен файлами. Значительная часть интеграций с 1С в России по-прежнему строится на файловом обмене по стандарту CommerceML — унифицированному XML-формату, который был разработан компанией «1С» совместно с «Extra.RU» при поддержке Microsoft ещё в 2000 году и с тех пор используется как фактический стандарт для передачи каталогов, цен, остатков и заказов между 1С и сайтами [5]. У стандартного варианта со стандартными XML-файлами обмена есть и недостатки — прежде всего по скорости и по контролю версий данных, — поэтому для более сложных сценариев его дополняют или заменяют API-обменом или EDI-протоколами.

Персональные данные при передаче. Для любого транспорта фиксируют необходимый состав полей, основание обработки, роли и срок хранения. Канал защищают, доступ ограничивают, события журналируют, а тестирование проводят на обезличенной выборке. Конкретные меры выбирают по применимым требованиям 152-ФЗ и модели угроз системы [11][12].

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

Как устроен процесс обмена данными: на что обратить внимание при проектировании

Независимо от выбранного способа, при проектировании интеграции стоит заранее ответить на несколько вопросов.

Какие системы участвуют и что из данных передаётся. Нужно явно зафиксировать источник и приёмник для каждого типа данных (например: заказы — из сайта в CRM, статус оплаты — обратно на сайт), а не полагаться на то, что маршрут «сложится сам».

Как происходит авторизация. Для API это чаще всего API-ключи, OAuth-токены или сертификаты; слабое место здесь — токены без срока действия и API-ключ как единственный механизм проверки подлинности запроса, без дополнительных проверок [17]. Для файлового обмена — это учётные данные для доступа к SFTP-серверу или облачному хранилищу, которые тоже нужно защищать и регулярно менять.

Как обрабатываются ошибки. HTTP-код не всегда сообщает окончательный бизнес-результат: запрос может завершиться таймаутом после фактической обработки, вернуть 202 Accepted или продолжиться через webhook. Для API, очереди и файлов нужны correlation ID, журнал статусов, идемпотентный ключ, контролируемые повторы и очередь ручного разбора. Для файла дополнительно проверяют целостность и признак завершённой записи.

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

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

Безопасность API: на что обращают внимание при проверке

Сообщество OWASP ведёт отдельный рейтинг наиболее критичных рисков безопасности API (OWASP API Security Top 10), и значительная часть пунктов в нём связана именно с контролем доступа — когда один пользователь или система могут получить доступ к чужим данным или чужим действиям из-за того, что проверка авторизации выполняется на уровне пользователя, но не на уровне конкретного объекта или операции [15]. На практике при проверке интеграции стоит убедиться, что: входные данные валидируются, для каждого эндпоинта настроены отдельные проверки авторизации, объём отдаваемых данных ограничен необходимым минимумом, а частота запросов (rate limiting) контролируется, чтобы избежать перегрузки или подбора данных [16].

Практические этапы внедрения интеграции

1. Зафиксировать бизнес-задачу. Что должно происходить: заказ должен появляться в CRM в течение минуты после оформления на сайте, или достаточно синхронизировать остатки раз в сутки?
2. Проверить возможности обеих систем. Есть ли у каждой системы документированный API, поддерживается ли выгрузка в файл, какие форматы и протоколы доступны.
3. Выбрать архитектуру обмена — API, файлы, промежуточную базу/очередь или их комбинацию — исходя из требуемой скорости, объёма данных и количества систем-участников.
4. Спроектировать обработку ошибок и повторов, включая ситуацию, когда одна из систем временно недоступна.
5. Учесть требования к защите данных, если через интеграцию передаются персональные данные или сведения ограниченного доступа.
6. Настроить тестовую среду и прогнать сценарии на обезличенных данных.
7. Организовать мониторинг и логирование обмена в промышленной эксплуатации.
8. Определить ответственных на стороне каждой из интегрируемых систем на случай сбоя.

Ограничения, ошибки и риски

Типичные ошибки при выборе и реализации интеграции:

• Выбор API «по умолчанию» без проверки доступности. Наличие документации API ещё не гарантирует, что доступ к нему открыт — часто требуется договор, регистрация или согласование с владельцем системы.
• Файловый обмен без защиты канала. Передача файлов с персональными данными по обычному FTP без шифрования — прямое нарушение требований к защите персональных данных.
• Отсутствие обработки повторов и задвоений. Если система-приёмник не проверяет, обработан ли уже файл или сообщение, при сбое и повторной отправке данные задваиваются — заказы, платежи, остатки.
• Игнорирование асинхронности там, где она нужна. Попытка сделать всё синхронным API-вызовом там, где одна из систем не может ответить мгновенно (например, тяжёлая выгрузка данных), приводит к таймаутам и нестабильной работе.
• Излишне сложная архитектура для простой задачи. Разворачивать полноценную интеграционную шину для связи двух систем — избыточно и увеличивает стоимость поддержки без реальной пользы.

Рекомендации по выбору решения

Если коротко резюмировать логику выбора:

• Нужен обмен в реальном или близком к реальному времени, у обеих систем есть API → выбирайте API-интеграцию.
• У одной из систем нет API, но есть выгрузка в файл, а скорость не критична → файловый обмен, желательно по защищённому протоколу (SFTP) или с шифрованием самих файлов.
• Систем много, и связи между ними усложняются с каждым новым сервисом, либо нужна гарантированная асинхронная доставка → промежуточная база, очередь сообщений или интеграционная шина.
• Задача разовая и небольшая → часто достаточно готового сервиса-коннектора или простой настройки без разработки — не всякая интеграция требует индивидуальной разработки.

В реальных проектах эти подходы часто комбинируются: часть данных идёт через API в реальном времени, а часть — периодическими файлами, если это не критично для бизнес-процесса.

Как может помочь «Пятый фактор»

Основная сложность интеграции обычно связана не только с выбором технологии — API, файлов или промежуточной базы, — но и с сопоставлением данных между системами, обработкой ошибок и последующим контролем за тем, что обмен продолжает стабильно работать. На сайте «Пятого фактора» есть инструмент подбора готовых решений по названию двух систем, которые нужно связать: в зависимости от возможностей конкретных систем это может быть готовый коннектор, интеграция через API, обмен файлами или через промежуточный сервис [10]. Если готового решения под конкретную пару систем ещё нет, команда может изучить существующий процесс и предложить архитектуру обмена под конкретную задачу.

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

Вывод

Выбор между API, файлами и промежуточной базой данных — это не вопрос вкуса или технологической моды, а вопрос конкретных ограничений: что умеют сами системы, какая скорость обмена реально нужна бизнесу, сколько систем предстоит связать и кто будет отвечать за интеграцию после её запуска. API даёт скорость и меньше ручной работы, но требует наличия доступного интерфейса с обеих сторон. Файловый обмен проще и устойчивее к разнородности систем, но не подходит для мгновенной синхронизации. Промежуточная база или шина оправданы, когда систем много или когда критична надёжная асинхронная доставка. Чем раньше эти ограничения проговорены и задокументированы, тем меньше риск, что интеграцию придётся полностью переделывать после запуска.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] habr.com — Технологии интеграции информационных систем. Часть 1. Файловый обмен, общая БД, удалённый вызов процедур — https://habr.com/ru/articles/841862/

[2] habr.com — Интеграция на основе сообщений. Преимущества и отличия от других подходов — https://habr.com/ru/articles/326088/

[3] kt-team.ru — Методы интеграции API: REST, SOAP, GraphQL — https://www.kt-team.ru/blog/api-integration-best-practices

[4] iflex.ru — Что такое API интеграция: принцип работы, разновидности и плюсы для бизнеса — https://iflex.ru/blog/chto-takoe-api-integraciya/

[5] beseller.by — Как импортировать на сайт каталог и товары из 1С через CommerceML — https://beseller.by/pomoshh/faq/import-1c-commerceml.html

[6] linkedin.com — What are the pros and cons of using RESTful APIs vs message brokers for software integration — https://www.linkedin.com/advice/0/what-pros-cons-using-restful-apis-vs-message

[7] medium.com — How should my services communicate with each other? (REST API vs Message Queue) — https://medium.com/@ilantentser/how-should-my-services-communicate-with-each-other-7fce746a8a1a

[8] dev.to — 7 API Integration Patterns: REST, gRPC, SSE, WS & Queues — https://dev.to/pasksoftware/7-api-integration-patterns-rest-grpc-sse-ws-queues-206o

[9] surf.ru — ESB — что такое интеграционная шина предприятия 2026 — https://surf.ru/esb-integracionnaya-shina/

[10] 5factor.ru — Что с чем нужно связать? — https://5factor.ru/svyazat-sistemy/

[11] consultant.ru — Федеральный закон «О персональных данных» от 27.07.2006 N 152-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_61801/

[12] staffcop.ru — Требования 152-ФЗ к защите персональных данных — https://www.staffcop.ru/blog/kak-vypolnit-trebovaniya-152-fz-zakona-o-personalnykh-dannykh/

[13] mfadhel.com — 3 Common Misunderstandings of Inter-Service Communication in Microservices — https://mfadhel.com/rest-message-queue/

[14] 8host.com — Использование SFTP для безопасного обмена файлами — https://www.8host.com/blog/ispolzovanie-sftp-dlya-bezopasnogo-obmena-fajlami-s-udalennym-serverom/

[15] habr.com — Перевод OWASP API Security Top 10 — https://habr.com/ru/companies/owasp/articles/547174/

[16] codeby.net — Защита API: OWASP Top 10 и примеры на Python — https://codeby.net/threads/prakticheskoye-rukovodstvo-po-zashchite-api-ot-owasp-top-10-uyazvimostei-primery-na-python.85316/

[17] codeby.net — OWASP API Top 10: методика пентеста всех 10 категорий — https://codeby.net/threads/prakticheskaya-bezopasnost-api-owasp-api-top-10-tipovyye-uyazvimosti-i-metodika-testirovaniya.92694/

[18] datafinder.ru — Выбор инструмента ETL/ELT для ClickHouse: обзор Apache NiFi и Apache Airflow — https://datafinder.ru/products/vybor-instrumenta-etlelt-dlya-clickhouse-obzor-apache-nifi-i-apache-airflow