Как подготовить сайт к будущему приложению

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

Такой задел полезен, когда приложение входит в план развития. Если задачи неясны, не стоит оплачивать архитектуру «на любой случай». Лучше договориться, что необходимо сейчас, что можно добавить позже и какие изменения потребуются.

Назначьте источник для каждого вида данных

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

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

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

Если вы планируете сайт на 1С-Битрикс, обсудите будущий обмен до выбора окончательного состава решения. Наличие CMS само по себе не подтверждает, что все нужные мобильные действия доступны без доработок. Это проверяют по конкретным данным и операциям.

Опишите API через действия пользователя

API — согласованный способ, которым приложение запрашивает сведения и передаёт действия серверу. Для заказчика полезнее список операций, чем перечень технологий: показать заказы клиента, получить документ, изменить контакт, повторить заказ. У каждой операции должны быть понятны входные данные, результат и возможные ошибки.

Не ограничивайтесь формулировкой «подключить приложение к базе». Прямое чтение таблиц не описывает, кто имеет право выполнить действие и какие проверки нужны. Удобная интеграция опирается на согласованный интерфейс и правила, а не на знание внутреннего устройства сайта.

Попросите включить описание API в передаваемые материалы проекта. Например, стандарт OpenAPI предназначен для описания HTTP API независимо от языка программирования. Такой документ помогает понять доступные запросы и ответы, но сам по себе не создаёт интеграцию и не гарантирует её корректность.

Для одного основного сценария полезно сделать проверку ещё до мобильного дизайна. Может ли отдельный клиент получить нужные сведения и выполнить действие без открытия страницы сайта? Какие данные отсутствуют? Ответы показывают объём подготовки точнее, чем общее обещание совместимости.

Согласуйте общие аккаунты и правила операций

Решите, как существующий клиент войдёт в приложение и увидит свою историю. Новый экран входа не должен незаметно создавать второй аккаунт без прежних заказов. Способ сопоставления аккаунтов, восстановления доступа и изменения контактов нужно описать отдельно.

Также определите роли. Покупатель, менеджер и сотрудник компании-заказчика могут видеть разные данные. OWASP рекомендует проверять разрешения при каждом запросе. Поэтому одинаковые ограничения должны действовать независимо от того, отправлено действие с сайта или из приложения.

Разберите несколько ситуаций до оценки:

• Клиент меняет данные на двух устройствах.
• Заказ отменён, пока приложение показывало старый статус.
• Пользователь повторно нажал кнопку после задержки ответа.
• Доступ сотрудника отозван, но приложение ещё открыто.
• Связь пропала между отправкой действия и подтверждением.

Для каждой ситуации нужен ожидаемый результат, понятный пользователю и сотрудникам. Это не требование реализовать все будущие возможности сейчас. Это способ обнаружить правила, которые уже важны для сайта и позже будут использоваться во втором канале.

Зафиксируйте границы задела и порядок обновлений

Разделите работу на необходимое для сайта, подготовку общего интерфейса и будущую мобильную часть. Напротив каждого пункта укажите, какой известный сценарий он поддерживает. Если назначение объясняется только словами «вдруг понадобится», пункт стоит обсудить отдельно, а не автоматически включать в первую смету.

Продумайте совместимость обновлений. После изменения сервера у части клиентов может остаться прежняя версия приложения. Поэтому изменения запросов и ответов нужно планировать так, чтобы согласованные поддерживаемые версии продолжали работать. Порядок проверки и вывода старых версий из поддержки лучше закрепить заранее.

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

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

Источники

• OpenAPI: спецификация интерфейсов HTTP API — назначение машиночитаемого описания операций и данных.
• OWASP: проверка прав доступа — проверка разрешений для каждого запроса и объекта.