1С и Web API: обмен, которому можно доверять

Надёжная интеграция начинается с ответа на вопрос: что произойдёт, когда один и тот же документ придёт дважды?

Контракт важнее транспорта

HTTP и JSON решают передачу данных, но не их смысл. В контракте фиксируют обязательные поля, типы, валюту, точность сумм и значение пустого поля. Отсутствующее значение и явное удаление — разные операции. Версию контракта стоит передавать явно, чтобы обновление конфигурации 1С не меняло поведение сайта неожиданно.

GUID и идемпотентность

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

Очередь и конфликт версий

Приём запроса и применение документа полезно разделить. Сначала запись попадает в очередь, затем валидируется и сопоставляется. Конфликт версий требует явного решения: применить источник, оставить приёмник или отправить на ручной разбор. Нельзя называть весь пакет успешным, если часть документов не прошла проверку.

Наблюдаемость и повтор

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

Документация и дальнейшее чтение

1C Developer Network ↗HTTP semantics, RFC 9110 ↗
Посмотреть в лаборатории