Вообще, если ты хотя бы раз настраивал обмен между 1С и внешней системой, то знаешь: это либо работает и ты доволен, либо работает, но ты уже седой. Или лысый. Зависит от частоты итераций. Но давай без пафоса — API в 1С:Предприятие есть, он рабочий, и если подходить с умом, можно спокойно организовать устойчивую интеграцию, не вызывая шамана.
Я не обещаю здесь рассказать всё и сразу — не тот формат. Но объясню, с чего начать, что выбрать, чего избегать и как сделать так, чтобы тебя потом не вспоминали недобрым словом, когда интеграция начнёт лагать.
Что вообще есть из API в 1С?
Вариантов, как подключиться к данным и функционалу 1С, несколько:
- COM-соединение (Automation Server)
- HTTP-сервис (веб-сервисы на WSDL или REST)
- Обмен по XML или JSON через HTTP-запросы
- Интеграция через прямой доступ к СУБД (что делать не стоит, но иногда делают)
- Встроенные обработки и расширения с внешним вызовом
- Обмен через очереди или файлы (FTP/SFTP, очередь сообщений)
На практике чаще всего используют HTTP-сервисы и REST-интерфейсы. Почему? Потому что COM — это хорошо, пока ты не хочешь масштабируемости и не упираешься в серверную архитектуру. Да и веб-сервисы в 2025-м уже звучат как что-то из пыльной книжки.
HTTP-сервисы: лошадка, которая ещё едет
Встроенные веб-сервисы (опубликованные через веб-сервер) — это базовый вариант интеграции. Их можно публиковать из конфигурации, определять нужные процедуры, и вызывать из внешнего мира через стандартные WSDL-запросы.
Минусы:
- Сложная генерация WSDL
- Устаревший SOAP-протокол
- XML-перегрузка и нечитабельность
- Трудности с аутентификацией
Плюсы:
- Работает из коробки
- Поддерживается всеми версиями 1С
- Можно управлять через роли, права, контексты
REST-интерфейсы и HTTP-сервисы руками
Если ты хочешь человеческую интеграцию, делай REST. Для этого 1С позволяет публиковать HTTP-сервисы с произвольной логикой: GET, POST, PUT, DELETE — всё это можно реализовать в серверных методах, обрабатывающих HTTP-запросы.
Это делается через HTTP-сервис с поддержкой вызова методов по URL. Внутри обрабатываются заголовки, тело запроса, формируется ответ.
Вот шаблон:
Процедура ОбработкаHTTPЗапроса(HTTPЗапрос, HTTPОтвет)
Путь = HTTPЗапрос.ПолучитьПуть();
Если Путь = "/api/getData" Тогда
// Обработка запроса
HTTPОтвет.УстановитьКодОтвета(200);
HTTPОтвет.УстановитьТело("Ответ в JSON");
КонецЕсли;
КонецПроцедуры
Тебе нужно самостоятельно реализовать маршрутизацию, валидацию, формирование ответа, логирование. Но ты получаешь гибкость: можешь делать всё, что нужно, и не ограничен рамками XML и WSDL.
Аутентификация и безопасность
Не забудь: по умолчанию 1С не шифрует трафик. Всегда используй HTTPS. Аутентификацию можно строить:
- По HTTP Basic (встроенный механизм)
- Через передачу токена в заголовке Authorization
- На основе собственной логики авторизации (например, API-ключи)
Никогда не пиши токены в URL и не передавай пароли в открытом виде. Логи пишутся. Службы слушают.
Обмен данными: XML, JSON, таблицы значений
1С умеет работать с разными форматами:
- XML — по умолчанию, особенно в веб-сервисах
- JSON — если делаешь REST и хочешь работать по-человечески
- CSV, XLSX — если интеграция примитивная, а данных немного
- 1С-объекты как строки — если интеграция внутренняя между базами
Работа с JSON в 1С нормальная. Есть ЧтениеJSON, ЗаписьJSON, структуры и массивы. Главное — валидировать данные, не надеяться, что внешний источник всё пришлёт корректно.
Что ещё есть полезного
- Регламентные задания — для обмена по расписанию
- Web-клиенты внутри 1С — чтобы вызывать внешние API
- 1С:Коннектор к внешним системам (например, к Bitrix24, amoCRM) — если хочешь готовые модули
И да, есть расширения конфигурации, через которые можно подключить свои модули интеграции, не трогая основную конфигурацию (что особенно важно для типовых решений).
Что не надо делать
Вот список того, за что тебя будут проклинать следующие интеграторы:
- Не публикуй COM-сервер на проде без надобности.
- Не пиши всё в одном модуле. Разделяй логику.
- Не пиши логин и пароль в коде.
- Не отдавай в JSON объекты с внутренними ссылками и метаданными 1С.
- Не используйте прямой доступ к базе, особенно в PostgreSQL. Структура может меняться.
И ещё: если делаешь публичный API — документируй. Хотя бы в Confluence. Хотя бы в .md-файле. Людям потом разбираться.
Итого
API в 1С есть. Он не идеальный, но достаточно гибкий, чтобы через него строить хорошие интеграции. Главное — выбрать правильный инструмент: HTTP-сервис для REST, веб-сервис — если надо срочно и “по старинке”, файл — если другая сторона не умеет ничего другого.
Умей договариваться с теми, кто будет это потом поддерживать. Делай так, чтобы API был читаем, безопасен, документирован и предсказуем. Это всё ещё 1С, но в 2025-м хочется уже делать интеграции по-человечески, а не шамански.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
