Клиентский опыт и архитектурный стиль RESTful

Разговоры о Customer Experience (опыте клиентского взаимодействия) ведутся уже так долго, что вряд ли способны привлечь чьё-либо внимание. Особенно внимание айтишников. Мол, это вообще не к нам. Есть специально обученные люди – дизайнеры, которые всё сделают правильно и непременно улучшат этот самый клиентский опыт. Архитектурный стиль RESTful, описанный Роем Филдингом аж в 2000 году в диссертации Architectural Styles and the Design of Network-based Software Architectures, привлечет не большие внимание тех же самых айтишников. Всё  ведь и так понятно. JSON поверх HTTP  – вот и весь RESTful. Давайте все же разберемся, о чем этот архитектурный стиль и как он связан с опытом клиентского взаимодействия.

Я не стану пересказывать работу Филдинга и даже модель зрелости REST API Леонарда Ричардсона. Если хотите, то почитайте в коротком пересказе и о том и о другом здесь: The REST Architectural Style. Мой тезис в том, что REST предоставляет очень понятный и удобный для клиента способ структурирования информации. Но этим его достоинства не ограничиваются. Выбирая приоритет данных перед функционалом, мы обретаем возможность понятным способом предоставлять функционала вслед за данным, а также эффективно его развивать, добавляя или переделывая микросервисы.

Теперь подробнее. Архитектурный стиль RESTful предполагает организацию всех имеющихся у нас данных в виде информационных ресурсов. Ресурс – это базовое понятие, столь же важное, как объект в объектно-ориентированном программировании. Организация ресурса может быть достаточно произвольной и допускает некоторый набор атрибутов и связей с другими информационными ресурсами. Единственное, что должен иметь ресурс, так это неизменную гиперссылку, по которой мы всегда можем к нему обратиться.

Ресурсы не типизированы, но для удобства работы они могут объединяться в коллекции. Один ресурс может входить в несколько коллекций и может сам содержать коллекции, как бы являясь контейнером для других ресурсов. Сами эти ресурсы не обязаны содержаться «внутри» рассматриваемого ресурса, а могут находиться в произвольном месте глобальной сети. Вместо содержания таких ресурсов контейнер хранит гиперссылки на них. Работа с ресурсами осуществляется посредством простых глаголов GET, POST, PUT, DELETE (методов протокола HTTP).

Довольно часто команды на изменение ресурсов реализуют в виде вложенных в него коллекций. Например, мы не списываем с банковского счета 10 рублей, а добавляем к ресурсу /account/75431 команду на списание в качестве нового вложенного ресурса в коллекцию /account/75431/write-off/ Команда эта будет выполнена асинхронно всякими сложными расчетными и банковскими системами. И рано или поздно списание произойдет, ну или не произойдет (См. HATEOAS: реализация функций в RESTful API).

Теперь вернемся к клиентам. По большому счету, всё что мне как клиенту хочется знать, так это что уже случилось и что потенциально может еще случиться. Для этого мне нужны данные – следы произошедших недавно событий. Если я клиент банка, то интересуют меня совершенные операции, выставленные счета, начисленные бонусы и закончившиеся вклады, ответы из службы поддержки на мои каверзные вопросы. Меня не интересуют функции. Я не собираюсь брать ипотеку, открывать кредитную карту и вступать в новую программу лояльности. Это всё нужно банку, а не клиенту. Вряд ли я лояльный клиент, потому как знаю, что банк непременно «забудет» уведомить менять о снижении начисляемого на остаток на карте процента, истечении срока или действия вклада(по крайней мере, один банк регулярно забывает об этом проинформировать) и прочих неприятных вещах. Поэтому главное, чего я хочу от банка, так это: быть в курсе происходящего!  Потому на главной странице интернет-банка или мобильного приложения я прежде всего ожидаю увидеть упорядоченную ленту сообщений: новые вверху, старые внизу. Быть может, сгруппированную по категориям(с количеством новых сообщений в данной категории). Практически как в мессенджере. Я не хочу видеть категории, которые ни разу не использовал. В принципе, вы можете даже не удалять кнопку «Начать чат» или «Взять кредит», пусть они просто опустятся вниз ленты, чтоб я никогда до них свою ленту не долистал. При выборе события из списка, появляется… Правильно! Не информация по событию, а информация по ресурсу, с которым оно связано: счету, поставщику услуг(инвойсов), бонусному балансу и т.п., а событие – просто первое в списке связанных с ресурсом сообщений. Здесь же, но никак не раньше, возможно появление операций. Но не всех, а только доступных для текущего ресурса.  Если у меня нет денег на счете, то я ничего не хочу знать о вкладе, который я мог бы открыть, если бы у меня эти деньги были.

Все эти вещи довольно просто реализуются в RESTful архитектуре. Более того, какие сообщения добавить в ленту, не надо решать прямо сейчас, в момент разработки приложения. Вы это сделаете потом, когда подключите новых поставщиков счетов за коммуналку, сборщиков налогов и штрафов ГИБДД, партнеров программы лояльности, финансовых брокеров и др. (если, конечно, у данного конкретного клиента буду операции именно с ними). Естественно, переписывать приложения для этого не придется. Добавление нового типа сообщений и операций с ними ограничится работой дизайнера. В крайнем случае, подключите в WebAPI новый микросервис для сбора событий из внешнего источника и обработки пользовательских команд. В общем, полный облом для системного интегратора, разрабатывающего вам личный кабинет или мобильное приложение: не будет у него новых релизов. Впрочем, если заранее не потребовать этого с внешнего разработчика, то новые релизы обязательно будут и не меньше двух раз в месяц, а на практике намного чаще: CI/СD и всё такое прочее – гибкое, модное, молодежное…

Клиентский опыт и архитектурный стиль RESTful: 4 комментария

    1. Спасибо за комментарий. Как сделать эту заметку понятней? Набросать эскиз пользовательского интерфейса мобильного приложения или же наоборот углубить тему RESTful API или что-то ещё. Что самое непонятное?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *