Отделите интерфейс пользователя от интеграции
Веб-клиент позволяет человеку работать с прикладным решением через браузер. Пользователь видит формы и выполняет предусмотренные операции. Браузер взаимодействует с веб-сервером, а дальнейшая работа зависит от архитектуры информационной базы и конфигурации. Интеграция решает другую задачу: одна система передаёт запрос другой и получает данные или результат операции. Например, сайт запрашивает доступность товара, а не открывает сотруднику форму справочника. Оба сценария могут использовать веб-технологии, но требования к интерфейсу, правам и обработке ошибок различаются.
Выберите механизм под договор обмена
Платформа поддерживает собственные HTTP-сервисы, автоматический REST-интерфейс и веб-сервисы, использующие SOAP. Также прикладное решение может обращаться к внешним сервисам. Наличие возможностей не означает, что любой механизм одинаково подходит конкретному проекту. Начните с договора обмена: какие поля передаются, какие обязательны, что считается успешным ответом и как обозначается ошибка. Укажите формат дат, чисел и идентификаторов. JSON описывает способ представления данных, но сам по себе не определяет смысл полей и правила доступа. Эти договорённости нужно зафиксировать отдельно и проверить на примерах.
Продумайте ошибки и повторные запросы
Сетевой запрос может завершиться тайм-аутом после того, как принимающая сторона уже выполнила действие. Если отправитель просто повторит создание документа, возникнет риск дубля. Поэтому для изменяющих операций заранее определяют способ распознавания повторов и получения текущего результата. Различайте транспортную ошибку, отказ доступа и нарушение бизнес-правила. Сообщение «не получилось» не помогает понять, можно ли повторить действие. В журнале полезны время, идентификатор запроса и безопасное описание результата. Пароли, токены и избыточные персональные данные в диагностические записи не включают.
Проверяйте на учебной среде
Публикация базы и настройка внешнего доступа требуют ответственного администрирования. Для изучения архитектуры не нужно открывать рабочую систему в интернет. Используйте схему или отдельную тестовую среду с вымышленными данными и минимально необходимыми правами. Перед реальным внедрением проверяют совместимость конкретной версии платформы, конфигурации, браузера и серверных компонентов по актуальной документации. Защищённое соединение и проверка личности пользователя не заменяют ограничения разрешённых операций. После настройки важно проверить не только успешный сценарий, но и запрет лишнего доступа, неверные данные и повтор одного сообщения.
Попробуйте на практике
Спроектируйте на бумаге получение остатка товара из учебной системы.
- Нарисуйте три участника: сайт, точку обмена и информационную базу. Отдельно обозначьте сотрудника, работающего через браузер.
- Опишите запрос с вымышленным идентификатором товара и ответ с количеством и единицей измерения.
- Предусмотрите три результата: товар найден, товар неизвестен и доступ запрещён.
- Запишите, какие данные нужны в журнале проверки и какие сведения туда попадать не должны.
Как проверить результат. Браузерная работа отделена от машинного обмена, поля имеют понятный смысл, ошибки различимы, а упражнение не требует изменения рабочей базы.
Частые вопросы
HTTP-сервис автоматически является готовым сайтом?
Нет. Он предоставляет точку взаимодействия для запросов. Пользовательский интерфейс и логика внешнего приложения являются отдельными частями решения.
Почему нельзя просто повторять любой запрос после ошибки?
Неизвестно, выполнила ли другая сторона действие до обрыва связи. Для операций записи нужен заранее предусмотренный способ проверки результата и защиты от дублей.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.