Что такое сбер id

Обновлено: 25.04.2024

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

Что такое Сбер ID

Для клиентов Сбера идентификатором является мобильное приложение и номер телефона, для остальных – только номер телефона. Через защищенную авторизационную зону пользователь может осуществлять единый вход в сервисы банка и партнерских компаний. Для этого достаточно перейти по ссылке для входа через Сбербанк Онлайн, и подтвердить его. Информация о клиенте будет автоматически передана на сайт компании-партнера.

Как получить Сбер ID

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

Для остальных категорий пользователей (не клиентов) также возможно получение идентификатора через официальный сайт. Данная процедура включает в себя следующие действия:

На сайте Сбербанка перейти в раздел «Онлайн-сервисы» и выбрать вкладку Сбербанк ID.
Открыть ссылку «Личный кабинет Сбербанк ID» и затем внизу страницы выбрать кнопку «Создать».
Подтвердить, что пользователь не является клиентом банка и у него не подключен Мобильный банк.
Указать свой номер (допускаются лишь номера российских операторов).
На открывшейся форме ввести ФИО, e-mail.
Подтвердить процедуру.

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

Как пользоваться идентификатором Сбербанка

Технологическое решение от Сбера можно использовать для быстрого входа на сервисы партнеров аналогично тому, как это можно сделать через аккаунты Google, Яндекс, ВКонтакте и других ресурсов.

выбрать сервис или сайт партнера;
подтвердить вариант входа через Сбербанк ID.

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

Как узнать Сбер ID в Сбербанк Онлайн

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

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

Как узнать Сбер ID через телефон

Для восстановления идентификатора Сбербанка через мобильный телефон нужно:

Как узнать Сбер ID через банкомат

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

Также можно подключить систему подтверждения входа в личный кабинет через одноразовый код – несмотря на определенные неудобства это позволяет значительно усилить безопасность системы. Таким образом клиент, регистрирующийся на сайтах партнерах через Сбер ID сможет ввести полученные данные и зарегистрировать акканут.

ОНЛАЙН ЗАЙМЫ Быстро. Легко. Одобоение займа сразу - 24/7. Деньги у Вас через 10 минут. Получите одобрение кредита Онлайн - отправьте заявку

Большинство операций, совершаемых клиентами через десктопную версию сервиса Сбербанк Онлайн, требуют подтверждения. Оно представляет

Экспертная оценка объекта недвижимости – неотъемлемый этап оформления ипотечного кредитного договора. Кроме того, необходимость

Реалии современной действительности таковы, что без банковских карт человеку сложно чувствовать себя комфортно. Сбербанк

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

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

Чтобы войти в личный кабинет, для начала его нужно зарегистрировать и получить логин (идентификатор пользователя) и пароль. Разберемся, как можно получить данные для входа и что делать, если логин или пароль утерян, или забыт.

Идентификатор пользователя: что это такое

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

После входа в систему, клиент может пользоваться всеми услугами интернет-банкинга:

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

Идентификатор пользователя должен находиться в недоступной для третьих лиц месте. Получить его может только владелец пластиковой карты и никто иной.

Как получить идентификатор пользователя для личного кабинета

Есть несколько вариантов того, как получить логин и пароль от личного кабинета:

по телефону;
через банкомат или терминал;
через интернет на сайте банка;
в офисе компании.

Рассмотрим подробнее каждый вариант.

При помощи мобильного телефона через службу поддержки клиентов

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

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

Через банкомат

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

Нельзя оставлять квитанцию в банкомате или выкидывать в урну, так как сведения станут доступны третьим лицам.

Через Сбербанк Онлайн на сайте финансовой компании

Здесь необходимо будет ввести номер своей банковской карточки и нажать конку «Продолжить» . Подтвердить операцию нужно при помощи смс – кода, который будет выслан на мобильный телефон.

В отделении банка

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

Как восстановить логин и пароль

Если данные для входа в систему были утеряны или забыты, восставить их можно теми же способами. Алгоритм действий идентичен. Однако самый доступный и простой вариант восстановления – через сайт банка.

Для этого нужно:

Зайти на страницу Сбербанк Онлайн.
Нажать кнопку «Забыли логин или пароль»
Выбрать вариант восстановления: смена пароля или восстановление логина.
Далее необходимо следовать указаниям системы.

Все операции будут подтверждаться смс-кодом, поступающим на мобильный телефон.

Заключение

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

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

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

А теперь самый главный вопрос — зачем? Зачем смешивать покупку пиццы и все свои накопления, поездку в такси и деньги на черный день?

Именно это и дает шанс мошенникам — создаешь сайтик, косишь под какой-нибудь сервис, делаешь заманчивые цены, льешь траффик. Далее человек регистрируется, что бы получить плюшки задешево — вводит почту, пароль, каптчу. А каптча не проходит (и никогда не подойдет — так задумано специально) после нескольких попыток регистрации он видит заветную кнопку — войти через Сбер — открывается окно, идентичное сайту Сбера (адресная строка обычно скрыта в таких мини окнах). В общем пользователь вводит логин пароль, потом приходит смс от самого сбербанка о входе в Сбербанк онлайн. И вуаля — вы залогинились на сайте, а мошенники в вашем онлайн — банке. Откуда же вам знать, что этот сайт не партнер банка, если 5 плойка со скидкой 70% туманит мозг?

Даже если сберID предусматривает вход только через сканирование QR кода приложением в телефоне, все равно найдутся те кто этого не знают. Мне так и не ясно как работает Сбер ID, так как конференцию я не смотрел(таких большинство) и нигде четко не написан процесс авторизации через него.

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

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

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

О чем пойдет речь

Мы расскажем, как в мобильном и веб приложениях Сбербанк Онлайн работают платежные сценарии, а именно про API между приложениями и сервер-сайдом.

Почему фокус на API? Все просто – это фактически единственный мостик, который соединяет клиентские приложения и бэкенд. Если проект небольшой, то мы можем легко менять API и переписывать под него приложения. Но если проект масштабный (такой, как у нас), то даже небольшие изменения API требуют вовлечения большого количества ресурсов как на фронте, так и на бэкенде, и становятся очень дорогими. И второй момент – чем раньше мы зафиксировали API, тем раньше фронтальные и бэковые команды могут начинать разработку. Им просто надо будет сойтись в одну точку.

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

Специфика и мотивация

Приложения большие. Когда мы писали эту статью, приложение Сбербанк Онлайн на Android занимало около 800 000 строк кода, на iOS – 500 000 строк кода. И это только наш код, без подключаемых библиотек.

Обратная совместимость и много пользователей. MAU – 32 млн активных пользователей мобильного приложения. И если мы не сделаем обратную совместимость на уровне API, очень многим пользователям по всей стране придется качать приложения заново. Это очень нехорошо. Кстати, это одна из причин, почему у нас так много кода.

Сбербанк Онлайн разрабатывает много небольших команд. Вы, наверное, слышали про Agile в Сбербанке. Это правда, мы работаем по Agile в командах по 9 человек.

Приложение банковское: несмотря на то, что функциональность банковских приложений растет очень быстро, основное, что происходит в дистанционном банкинге – это последовательный процесс (обработка клиентских заявок). Такие процессы мы называем workflow. Заявки эти могут быть разного рода и обрабатываются они огромным количеством взаимосвязанных сервисов в периметре банка.

Два типа команд. Есть платформенные – они отвечают за разработку ядра приложения. И есть фичёвые команды – они создают прикладной функционал для конечных пользователей, используя архитектуру и инструменты, которые даёт платформа.

Омниканальность. Крайне важная история. Чтобы не разрабатывать бэк несколько раз – отдельно для мобильных приложений и отдельно, например, для веб-версии и банкоматов, нужно сделать так, чтобы API был максимально схожим для всех каналов (как минимум должна быть одинаковой структура ответа).

Мобильное приложение

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

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

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

Если обобщить все эти требования – приложения должны разрабатываться на нативных языках, иметь повторно используемые компоненты внутри себя, но при этом вся бизнес-логика должна управляться со стороны сервера.

Как делать не стали

После того как мы обозначили граничные условия, расскажем, какие существующие решения мы анализировали.

Программирование на JSON

Логику проще описать императивно кодом, чем выдумывать (и изучать!) новый декларативный язык, который всегда будет ограничен сильнее, чем родной язык платформы. Кроме этого, надо предусмотреть песочницу, обработку ошибок, какой-то этап пилотирования – псевдокод должен постепенно распространяться на пользовательские устройства и при любых сбоях откатываться назад. Всё это усложняет разработку без ощутимых преимуществ.

Не используем описание стилей компонентов, поскольку они могут разниться от форм-фактора, платформы и даже режима работы (портретная/ландшафтная ориентация, responsive в web). Декларации стилей в конечной реализации всегда будут качественнее, ближе к реальности и корректнее работать с краевыми случаями. Кроме этого, бывает, что компоненты со схожей логикой принципиально по-разному работают на разных устройствах: например, ввод номера телефона – с телефонной книгой на мобильном устройстве и без неё в вебе.

Фиксация модели данных в интерфейсе приложения

Этот способ еще называется «прибить гвоздями». Смысл в том, что интерфейс приложения строится на уникальных идентификаторах объектов, которые передаются с сервера. В такой схеме любые изменения на стороне сервера приводят к переработкам клиентской части. Невозможно повторно использовать код. Сложно поддерживать.
Единственное, почему стоит выбирать такой способ на своем проекте, – уверенность на 99%, что API не будет меняться. Ну или если проект совсем небольшой и проектировать API дороже, чем быстро переделать пользовательский интерфейс под изменения в API.

Добавляем к каждому объекту признак стиля. UI приложений строим на основании этого признака. Стилей ограниченное число, поэтому появляется возможность строить интерфейс динамически. Но с увеличением функциональности UI приходится увеличивать количество стилей.
В этом варианте становится возможно управлять отображением отдельных элементов, но повышается сложность реализации связанности между разными полями. И главное – с ростом вариативности UI у вас будет постоянная необходимость расширять протокол API.

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

Web Components / React Components API

Концепция веб-компонентов, которая в том числе значительно повлияла на API компонентов React, нам подходит уже намного лучше: с одной стороны, у нас есть контроль за отображением, с другой стороны – есть возможность привязывать данные к элементам UI.
К сожалению, всё слишком сильно завязано на HTML + CSS + JS. Напрямую не используешь, но запомним – потом пригодится.

Как решили делать

UI-контейнеры

Объекты упаковываются в контейнеры, презентационную логику приложения строим на этих контейнерах. Основное преимущество – можем группировать несколько простых объектов в один контейнер. Это дает свободу в программировании UX/UI на клиенте, например, можем управлять скрытием/отображением одного поля при заполнении данных в другом. При этом базовых типов объектов – ограниченное число, и весь бизнес-транспорт реализуется на них.

Мы выбрали именно этот подход. Сначала мы опишем протокол API, а потом – как устроены фрэймворки внутри мобильных и веб-приложений.

Чтобы было понятнее, рассмотрим API на примере простого процесса, например, перевод между своими счетами. Как добираемся до точки входа, не рассматриваем – это не процесс и для этого есть свой API (о нем мы тоже как-нибудь расскажем). Итого, процесс у нас начинается с точки входа:

Транспорт данных

Для начала договоримся об основных принципах – как передаём данные. За основу возьмём самый простой подход – пары «ключ-значение». Ключом пусть будет строка из букв латинского алфавита, значение – тоже строки, но уже произвольные.

Формы для заполнения бывают сложные, с вложенными элементами и подразделами, значит, надо допускать вложенность. Можно именовать ключи в формате camelCase, но они могут быть плохо читаемым (например, в логах) или даже «портиться» в системах, нечувствительных к регистру. Нужно ввести разделитель.

Самый очевидный разделитель – точка – во многих языках используется для доступа к свойствам объекта. При неаккуратном использовании ключи с таким разделителем будут создавать словари (или объекты), в которых возможны коллизии. Например, “foo.bar” = “foobar” и “foo.bar.baz” = “foobarbaz” в javascript может повлечь перезапись свойства “bar” объекта “foo” со строки на объект. В конце концов, договорились на двоеточии: с одной стороны, явное визуальное разделение и семантическое отражение вложенности, с другой стороны, достаточно безопасно для всех используемых языков.

Что делать с повторяемыми полями? Вводим дополнительное правило: между парой разделителей могут быть либо латинские буквы, либо цифры. Получаются конструкции вида: children:5:name:first.

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

Решение: значение – либо строка, либо список строк. Так решение выглядит типовым, но в то же время накладные расходы оказываются незначительными.

Шаг – это состояние процесса. Первый шаг у нас – выбор счета списания и счета зачисления и ввод суммы.

UI на этой картинке не видно, потому что шаг – это про серверную логику, а не про презентационную. Есть два подхода к работе с шагами: можно передавать с сервера только разницу (нарастающий итог в клиентском приложении) или каждый шаг целиком (нарастающий итог на сервере).

Анализ требований показал, что в ходе процесса экран может формироваться по-разному на разных шагах (ветвление процессов), поэтому вместо добавления управляющих команд для преобразования уже переданных сущностей проще каждый шаг передавать полностью таким, каким его должен увидеть пользователь.

Из дополнительных плюсов: при возврате к редактированию не нужно проигрывать весь сценарий или передавать дополнительный параметр “отдай всё”. При старте шага клиентское приложение сразу же получает всю нужную информацию для построения экранов.

Экраны

Экран – это разделение процесса на этапы в клиентском приложении. Как правило, экраны используются, чтобы форма была проще для восприятия. В нашем случае всё просто: один шаг – один экран.

Для экранов мы ввели два правила:

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

UI компоненты (блоки)

UI компонент – независимый компонент, который реализует клиентскую логику и наполняет документ данными. По сути, это ассоциация между управляющей командой в протоколе и куском кода и разметки в приложении. На первом экране три компонента:

Счет списания
Тот же компонент для счета зачисления
Сумма перевода

Поля – это атомарные компоненты, которые выступают транспортом для отдельных элементов данных и обрабатывают пользовательский ввод в случае деградации блока. Типов полей ограниченное число и все они поддерживаются на уровне фрэймворка: text, checkbox, select, multiselect.

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

Поля в UI-компонентах из нашего примера:

1. Поле со ссылкой на справочник в счете списания и счете зачисления. Почему ссылка на статический справочник? Потому что счет мы выбираем из списка карт (счетов), без лишнего обращения к серверу.

2. Два отдельных поля для суммы и валюты в компоненте ввода суммы

Таким образом, формат для полей имеет такую структуру:

События

Так как приложения ничего не знают о процессе, логично, чтобы события (кнопки, которые видит пользователь) тоже были частью ответа от сервера.

События мы разделили на два типа.

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

2) И специальные – для нестандартных действий, которые мы заранее спрогнозировать не можем, да и смысла закладывать их в часть движка нет, так как они редко используются.
В нашем случае на экране только основные события – «продолжить» и «назад». Они реализованы на уровне платформы.

У всех событий есть ряд атрибутов, такие как сам тип события, title и признак видимости. И никакого UI на сервер-сайде вроде размера кнопки, положения и цвета. Эта логика реализуется на фронте.

Справочники

Со справочниками все стандартно. Если он небольшой, то мы его присылаем полностью в ответе от сервера и называем статическим. Сделано это для того, чтобы минимизировать количество запросов к сервер-сайду и время отклика на действие пользователя в интерфейсе. Чтобы его отобразить в форме на экране, добавляем поле с типом – selectList, одно из свойств которого – ссылка на статический справочник.

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

Ошибки валидации на клиенте и сервере

Примерно так выглядит структура ответа:

Фрэймворки

Теперь немного о том, как с этим протоколом работают фрэймворки внутри приложений. Условно фрэймворки можно разделить на две основные части: workflow engine + обработчик UI-контейнеров. Такое разделение вызвано не только архитектурой приложений, но и организационной структурой. Движок разрабатывают и поддерживают платформенные команды, а UI-контейнеры фактически являются точками расширения и их программируют фичёвые команды. Таким образом, большему количеству команд не нужно вносить изменения в ядро.

Workflow engine

Движок внутри приложений (веб и мобильного) знает, что начался процесс работы с документом и что согласно протоколу ему придёт ряд атрибутов: шаги, экраны, UI-контейнеры и типы полей. На этих данных рисуется базовый интерфейс – нижнее и верхнее меню, основные кнопки, UI на простых типах полей, если они используются.

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

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

Как работают UI-контейнеры?

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

Поэтому нужны были точки расширения. Этими точками расширения стали UI-компоненты – это нативная реализация кода в самих приложениях, который идентифицируется движком по названию. По сути, это группировка поля/нескольких полей в логический блок, который может отображать кастомный UI. При этом модель данных протокола используются только для транспорта данных на бэкенд, весь UX и UI реализуется на стороне приложения.

Два режима работы фрэймворка

Когда движок парсит модель данных, он сравнивает список имен UI-контейнеров с реестром, который хранится внутри приложения. Если приложение не находит имени компоненты, то интерфейс строится на простых типах полей. Процесс будет полностью рабочим, но на стандартных UI-элементах.

Слева – как может отображаться контейнер для ввода суммы на списке из простых типов полей. Справа – если в сборке приложения есть UI-контейнер. Несмотря на то, что в режиме списка простых полей нет слайдера и есть отдельное поле вместо иконки с выбором валюты, – мы можем передать все данные с PL и процесс будет рабочим.

И тут мы получаем одно из основных преимуществ движка – доставить пользователю изменения без обновления приложения. В сборке есть маппинг имен компонентов на классы, в которых запрограммирован UI этих компонентов и пользовательский интерфейс строится на нем.

Каких правил мы стараемся придерживаться при работе с UI-компонентами:

Поддерживать работу функционала в режиме списка простых типов полей. У любого прикладного проекта есть соблазн превратить динамический протокол в статический. Поэтому мы всех просим сначала разработать функционал на типовом UI-контейнере, а потом обогащать UX/UI добавлением кастомных контейнеров на этой модели данных. Это не только позволит в будущем обновлять процессы на старых сборках, но и автоматически поддерживает логическую целостность API.
Не менять модель данных (JSON) для UI-контейнера, если он уже готов (проходит финальное тестирование или уже в продакшене). Так как логика на PL жестко связана с моделью данных, её изменение сломает функционал на версиях мобильного приложения, которые не обновляются. Тем не менее, модель можно расширять при условии сохранения обратной совместимости.
Называть свой UI-компонент системным именем. Так как имя UI-компонента – обязательный атрибут протокола и должен быть минимум один на каждом экране, мы ввели специальное системное имя, которые реализует простой список полей.
Не реализовывать бизнес-логику на UI-компонентах. Логику необходимо реализовывать на сервере, почему – писали выше.

Coming soon…

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

Пишите в комментариях, что непонятно, что интересно – постараемся писать меньше, но чаще и в цель. У нас много интересных вызовов, и поэтому много материала.

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: