REST API в 1С: HTTP-сервисы, OData и внешняя интеграция
REST API — транспортный способ, а не бизнес-результат. Сначала определяют, какие данные и события нужны внешней системе, кто ими владеет и как подтверждается результат. Затем выбирают произвольный HTTP-сервис, стандартный OData-интерфейс, middleware, файл или очередь.
Промышленный обмен требует авторизации, версии контракта, валидации, идемпотентности, ограниченных повторов, корреляционного ID и наблюдаемости. Посмотреть поведение этих механизмов можно в демонстрационном сценарии без обращения к реальным системам.
API — способ, а не бизнес-результат
Формулируйте цель как «заказ создаётся один раз и получает статус», а не «сделать REST». Это оставляет пространство выбрать безопасный механизм.
Контракт включает данные, владельцев, ошибки, SLA, восстановление и критерии приёмки.
HTTP-сервис в 1С
Платформа позволяет создавать произвольные HTTP-сервисы с шаблонами URL и обработчиками методов. Разработчик сам формирует коды, заголовки и тело ответа.
Это даёт узкий бизнес-контракт, но требует самостоятельно реализовать валидацию, права, версию и ошибки.
OData: преимущества и границы
Стандартный REST-интерфейс автоматически публикует объекты прикладного решения по OData. Он удобен для типовых операций и метаданных.
Широкий доступ к внутренним объектам увеличивает поверхность безопасности и связывает клиента со структурой конфигурации. Публикуйте только необходимое и используйте отдельные права.
Внешний middleware и очередь
Промежуточный слой отделяет 1С от внешних форматов, хранит очередь, ограничивает скорость и централизует мониторинг. Он полезен при нескольких системах и пиковых нагрузках.
Цена — отдельная инфраструктура и ответственность за эксплуатацию. Для малого синхронного потока она может быть избыточной.
Авторизация и хранение секретов
Используйте HTTPS, минимальные права, отдельную техническую учётную запись и ротацию. Токены и пароли не хранятся в коде, URL, журнале или форме сайта.
Проверьте отзыв доступа и истечение секрета до запуска.
Версия контракта и валидация JSON/XML
Схема определяет обязательные поля, типы, формат дат и допустимые значения. Неизвестное поле может игнорироваться, а отсутствие обязательного возвращает понятную ошибку.
Изменение контракта выпускается совместимо или под новой версией; обе стороны получают срок миграции.
Идемпотентность, retry и correlation ID
Ключ идемпотентности связывает повтор с прежним результатом. Retry ограничен и применяется только к временным ошибкам; бизнес-ошибка уходит на исправление.
Correlation ID проходит через 1С, middleware и внешнюю систему, позволяя собрать единую временную линию.
Негативные сценарии тестирования
Проверьте неверный JSON, пропущенное поле, чужие права, таймаут, повтор, изменение порядка сообщений, недоступность и восстановление. Ответ не должен раскрывать стек и секреты.
Нагрузочная проверка использует объём, близкий к ожидаемому, и контролирует влияние на пользователей 1С.
Проверочный сценарий
Запрос с idempotencyKey: demo-order-42 успешно обработан, но ответ теряется. Повтор возвращает прежний demo-document-17. Все попытки имеют один correlation ID; реальных токенов и клиентских данных в payload нет.
| Механизм | Подходит | Главная граница |
|---|---|---|
| HTTP-сервис | Узкий бизнес-контракт | Всё поведение проектируется |
| OData | Стандартные объекты | Связь со структурой конфигурации |
| Middleware | Несколько систем и очереди | Отдельная эксплуатация |
Чек-лист самостоятельной проверки
- Цель сформулирована через бизнес-результат.
- Контракт версионируется и валидируется.
- Секреты защищены, права минимальны.
- Повторы идемпотентны и ограничены.
- Негативные сценарии, журнал и мониторинг приняты.
Официальные источники
- 1С:Предприятие — HTTP-сервисы
- 1С:Предприятие — REST/OData-интерфейс
- 1С:Предприятие — работа с HTTP/HTTPS