REST API для 1С: как безопасно открыть данные приложению и боту

Задача: данные 1С нужны снаружи

Компания хочет приложение для торговых представителей, бот для клиентов с остатками и статусами заказов, личный кабинет дилера или витрину для партнёров. Все эти проекты упираются в один вопрос: как дать внешнему клиенту данные из 1С, не подставив под удар саму базу.

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

Почему нельзя публиковать 1С напрямую в интернет

Технически опубликовать базу 1С на веб-сервере и открыть доступ из интернета несложно. Именно поэтому так часто делают, и именно поэтому так часто случаются проблемы:

• Учётные данные в приложении. Чтобы ходить в 1С, приложению нужен логин и пароль пользователя 1С. Всё, что зашито в мобильное приложение, можно извлечь.
• Лишние права. Пользователь, под которым ходит приложение, часто видит больше, чем нужно приложению: все цены, всех контрагентов, иногда бухгалтерию.
• Нагрузка. Сотня клиентов, которые раз в минуту обновляют каталог, создают нагрузку, от которой медленнее работают бухгалтер и кладовщик.
• Поверхность атаки. Открытый наружу веб-сервер 1С становится целью для перебора паролей и сканеров уязвимостей.

Правильная схема: три слоя

Приложение не знает ни адреса 1С, ни пароля. Оно авторизуется на промежуточном сервере своим токеном. Промежуточный сервер решает, что этому клиенту можно, и при необходимости обращается к 1С по защищённому каналу. Каталог и остатки отдаются из кэша, а в 1С уходят только запросы, которые без неё не обработать: создание заказа, проверка свежего остатка.

HTTP-сервис в 1С: что в нём должно быть

HTTP-сервис добавляется в конфигурацию через расширение, поэтому типовая остаётся на поддержке. Хороший сервис для внешнего приложения устроен так:

1. Узкие методы. Не «отдать справочник целиком», а «каталог для клиента с ценами его типа», «остаток по списку позиций», «создать заказ», «статус заказа».
2. Свой пользователь с минимальными правами. Ровно на те объекты, которые нужны методам.
3. Проверка входных данных. Любой параметр проверяется: тип, длина, допустимые значения. Заказ с отрицательным количеством не должен дойти до записи.
4. Постраничная выдача. Каталог в десятки тысяч позиций отдаётся частями.
5. Изменения с момента. Метод «что изменилось с такого-то времени» позволяет обновлять кэш без полной выгрузки.
6. Понятные ошибки. Код и текст ошибки, по которым приложение покажет человеку осмысленное сообщение.

Авторизация и права клиентов

На промежуточном сервере каждый клиент получает свой ключ или вход по номеру телефона с кодом. Сервер знает, какому контрагенту или сотруднику в 1С соответствует клиент, и добавляет это ограничение к каждому запросу.

Дилер видит только свои цены и свои заказы. Торговый представитель видит только своих клиентов. Бот для покупателей видит каталог и статус конкретного заказа по номеру и телефону. Ограничение проверяется на сервере, а не в приложении: всё, что проверяется только в приложении, можно обойти.

Кэш и лимиты: чтобы база не падала

• Кэш каталога. Справочник товаров и цены меняются не каждую секунду. Промежуточный сервер обновляет их раз в несколько минут по методу изменений и отдаёт клиентам из памяти.
• Остатки. Для витрины подходит кэш с коротким сроком. При оформлении заказа остаток проверяется в 1С напрямую.
• Лимит запросов. Каждому клиенту задаётся предел числа запросов в минуту. Ошибка в приложении, которое зациклилось на обновлении, не положит базу.
• Очередь записи. Заказы при пиковой нагрузке ставятся в очередь и записываются в 1С последовательно, клиент сразу получает номер и статус «принят».

Журнал и мониторинг

Каждый запрос пишется в журнал: кто, когда, какой метод, сколько длился, чем закончился. Это нужно и для безопасности, и для разбора жалоб: «заказ не дошёл» проверяется за минуту по журналу, а не гаданием.

Мониторинг следит за временем ответа 1С и долей ошибок. Если 1С недоступна, промежуточный сервер продолжает отдавать каталог из кэша, а заказы копит в очереди. Ответственный получает уведомление, например в Telegram.

Пример набора методов для приложения торгового представителя

Чтобы схема была понятнее, вот как выглядит типовой набор методов для приложения, с которым торговые представители принимают заказы у клиентов.

Приложение при этом работает офлайн: каталог и клиенты хранятся в телефоне, заказы копятся и отправляются при появлении связи. Для торговых представителей в регионах с нестабильной мобильной связью это обязательное требование, а не опция.

Набор методов для бота или кабинета дилера отличается деталями, но принцип тот же: данные, которые меняются редко, из кэша, проверка в момент действия из 1С, запись через очередь.

Частые ошибки в таких проектах

• Один пользователь 1С на всех клиентов. Нельзя понять, кто что делал, и нельзя ограничить доступ по клиенту.
• Полная выгрузка вместо изменений. Каждое обновление каталога тянет всё заново и нагружает базу.
• Бизнес-логика в приложении. Скидки и проверки остатков считаются в телефоне, и разные версии приложения считают по-разному. Логика должна жить на сервере или в 1С.
• Нет версии API. Изменение метода ломает старые версии приложения, которые ещё стоят у половины пользователей.

Порядок работ

1. Описываем сценарии клиентов: что они видят и что делают.
2. Проектируем методы API и права.
3. Пишем HTTP-сервис в расширении и проверяем на копии базы.
4. Поднимаем промежуточный сервер с авторизацией, кэшем и лимитами.
5. Готовим документацию API для разработчиков приложения или делаем приложение сами.
6. Нагрузочная проверка и запуск.

HTTP-сервисы обычно занимают 2-3 недели, вариант с кэшем и лимитами от 4 недель, стоимость от 350 000 ₸. Подробнее на странице API для 1С. Если нужно и само приложение, смотрите мобильное приложение для 1С.