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

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

Зачем это дизайнеру

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

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

Немного вводных

Для начала — давайте вкратце пройдёмся по терминологии.

СУБД

Как я уже рассказывал в предыдущей статье, для управления базами данных требуется определённый софт. Без него БД — это просто файлы. Которые, к тому же, нельзя открыть обычными программами, вроде блокнота (чаще всего). Этот софт, необходимый для манипуляций с базами данных, называется СУБД — Системы Управления Базами Данных. Они позволяют создавать базы, структурировать, изменять/удалять/добавлять данные, защищать их и так далее.

Связи

Данные в БД должны быть связаны друг с другом. В основном, используются три вида таких связей (их ещё называют «кардинальность»):

• связь «один к одному»;
• связь «один ко многим»;
• связь «многие ко многим».

В чем их различие, понятно из названия. Но я всё равно немного расскажу об этом.

Один к одному (1:1)

Этот тип связи встречается довольно редко.

При связи «один к одному» объект из одной части БД может быть связаны только с одним объектом из другой части. Сложно, поэтому покажу на примере.

Классический пример связи «один к одному» — это серия и номер паспорта. Здесь каждый номер привязан к серии и наоборот. Серия паспорта без номера бессмысленна, равно как и номер без серии.

Иногда оказывается, что связь 1:1 — это просто ошибка проектирования. В нашем примере куда правильнее было бы сделать элемент «паспорт» со свойствами «серия» и «номер». А вот, например, связь «человек» и «паспорт» — хороший пример адекватного решения «один ко одному».

Где применяется:

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

Как реализуется в БД:

• Через внешний ключ, который является уникальным в обеих таблицах.
• Иногда — просто объединением таблиц, если нет причин их разделять.

Один ко многим (1:N)

В этом случае один объект может быть связан с одним или несколькими объектами в другой части БД. Но эти «вторые» объекты могут связаны только с одним «первым» объектом. Давайте снова на примере.

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

Где применяется:

• Самый частый тип связи в реальных моделях.
• Используется, когда есть чёткая «главная» и «зависимая» сущность.

Как реализуется в БД:

• В таблице «многих» хранится внешний ключ на «одного».
• Например: в таблице ordres есть колонка client_id, ссылающаяся на таблицу clients.

Многие ко многим (M:N)

Этот тип связи походит, когда связи могут «перекрещиваться» — когда один объект может иметь отношение к нескольким объектам из другой части БД, но и эти «вторые» объекты могут относиться к нескольким «первым» объектам.

Хороший пример — кино и актёры. В одном фильме могут сниматься несколько актёров (множественная связь «фильм-актёр»), но и у одного актёра может быть несколько фильмов, в которых он снимался (множественная связь «актёр-фильм»).

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

Где применяется:

• Когда обе стороны равноправны и могут иметь множество связей друг с другом.

Как реализуется в БД:

• Через промежуточную таблицу, которая хранит пары связей.
• Например: таблица actors_films с полями actor_id и film_id.

Виды баз данных

Все БД можно очень чётко разделить на виды — в зависимости от модели данных, которую они используют.

Иерархическая БД

В иерархической БД данные хранятся, как папки на компьютере: всегда есть родительские элементы, а есть дочерние. Этот вид является самым «древним» — первые БД были преимущественно именно иерархическими. В современном мире они применяются редко, разве что для очень специфических задач.

Здесь нельзя выстроить связи между данными типа «многие ко многим» — а это очень часто требуется в проектировании. Отчасти поэтому иерархический вид БД не особенно популярен.

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

Пример СУБД для иерархической базы данных — IMS от IBM.

Сетевая БД

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

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

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

Отдельного упоминания заслуживают так называемые «графовые» БД — разновидность сетевых. Не буду на них останавливаться, если интересно, загуглите сами.

Пример сетевой графовой СУБД, распространяемой по свободной лицензии — OrientDB.

Реляционная БД

Самый распространённый вид баз данных. Особенность реляционных БД в чёткой и понятной структуре информации, представленной в виде двумерных таблиц. В каждой такой таблице есть строки (собственно, объекты данных) и столбцы (свойства этих объектов). При этом столбцы, как правило, подчиняются очень чёткой типизации: конкретный столбец может содержать только один тип данных — например, строку или число. При этом одинаковых строк (элементов) в таблице не может быть.

На рисунке ниже «столбцы» представлены «строками» не только для удобства восприятия, но и потому что именно так обычно визуализируются реляционные БД (об этом я расскажу чуть ниже).

Вот так выглядит реляционная база данных в редакторе. По сути, каждая такая БД — это просто список тех самых двумерных таблиц:

А вот пример структуры отдельной таблицы. Слова «meta_id», «post_id», «meta_key» и «meta_value» — это те самые «столбцы», которые несут в себе свойства элементов:

И вот, наконец, уже сами данные этой самой таблицы. Здесь строки — это элементы (объекты данных), а у столбцов «meta_id», «post_id», «meta_key» и «meta_value» есть конкретные значения — свойства этих элементов:

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

Сейчас самая популярная реляционная СУБД — MySQL от Oracle.

Остальные виды

На самом деле, существует еще довольно много других видов БД: объектно- или документо-ориентированные, функциональные и разные смеси, вроде объекто-реляционных баз. Но это, чаще всего, диковинки, заточенные под выполнение конкретных, довольно специфических задач. Но если тема вас зацепила, можете погуглить.

Визуализация

Результатом проектирования БД должен стать какой-то графический или текстовый объект — здесь всё понятно. Обычно это схема или несколько таблиц, связанных между собой. Человечество придумало огромное количество способов передать структуру данных, но наибольшее распространение получила так называемая ER-модель (её ещё называют ER-диаграммой).

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

А вот — настоящая ER-диаграмма (к слову, отнюдь не самая большая):

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

В заключение

Конечно, это только начало. Я многое не рассказал, и не собираюсь — просторы интернета ломятся от серьезных, вдумчивых статей про базы данных. Но подступаться к ним с нулевого уровня знаний всегда очень сложно. Теперь же вы хотя бы немного погружены в контекст. Хотя бы понимаете, куда копать — если захотите, конечно.

Запись Дизайн данных (часть 5). Матчасть: базы данных. первой появилась на Павел Шерер.

Здесь (как и в следующих двух постах) речь пойдёт о самой трэшовой части дизайна данных: о хранении, передаче и типах данных, о работе и визуализации БД, даже о философии API и формировании запросов. В общем, полный фарш. Если честно, редкий продуктовый дизайнер владеет технической составляющей проекта на таком уровне. Более того, чаще всего он и не обязан всё это знать. Но ведь мы хотим быть лучшими из лучших, верно?

Разумеется, в рамках одной статьи невозможно рассказать всё. Поэтому моя задача сейчас — дать базис, ввести в терминологию. Чтобы потом каждый из вас мог посоветоваться с техническими специалистами, не испытывая при этом «эффекта вавилонской башни». А то и вообще самостоятельно прогуглить «белое пятно» знаний.

Итого, зачем изучать матчасть дизайна данных? Основных причин всего две:

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

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

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

Если я вас не убедил — добро пожаловать в комментарии, обсудим. Но сперва попробуйте прочитать статью полностью.

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

Погнали.

Способы хранения

Данные хранятся.

Кэп

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

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

То есть данные в красной области сохранялись на сервере, а в жёлтой — на клиенте (в нашем случае клиентом было выдуманное мобильное приложение; однако в случае сайта, например, клиентом выступает браузер). На диаграммке видно, что часть данных находится на стыке областей — то есть они хранятся и на клиенте, и на сервере.

При этом в обоих случаях (клиент и сервер) способы хранения информации примерно одинаковые. Чаще всего, применяется три типа хранения данных:

БД

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

Файлы

Да, обычные файлы. Чаще всего, вообще текстовые. Без проблем читаются любыми программами, умеющими читать текст. Файлы используются, в основном, для хранения статичной информации: вроде логов (например, история действий пользователя в консоли или ошибок работы сервера) или конфигурационных параметров (версия приложения, доступы к БД, URL API и прочее). Еще один пример хранения информации в файлах — это куки (cookies) в вашем браузере.

Память

Та самая, оперативная. Часть данных всегда хранится в памяти приложений (как клиентских, так и серверных). То, как приложение работает с памятью, всегда зависит от языка, на котором написано приложение. Например, PHP выполняет код только в процессе запроса — и память там чаще всего нужна только для обработки данных (но есть и исключения). Когда вы вводите пин-код в мобильном приложении, в большинстве случаев он сохраняется именно в памяти — и потом берется оттуда для подтверждения выполнения важных операций (например, для расшифровки пароля, записанного в БД). В случае с нашим выдуманным приложением про тюленей, данные о точках получаются с сервера и хранятся в памяти всё время сессии (или пока не выгрузятся оттуда специальным механизмом).

Далее мы будем рассматривать работу БД в деталях, а вот файлов и памяти больше не коснемся совсем. С файлами все просто, а чтобы описать работу памяти, не хватит и десятка таких статей.

Способы обмена

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

Давайте попробуем разобраться.

Протоколы

В сети всё завязано на протоколах. Если упростить, то протокол — это набор правил, по которым происходит отправка и приём данных. Если вы занимаетесь дизайном данных, понимание различий между протоколами необходимо хотя бы на самом верхнем уровне. Наиболее часто используемые сетевые протоколы:

• HTTP — де-факто стандарт работы всех этих сайтов, мобильных приложений и прочего. Имеет две версии: просто HTTP и HTTP/2. У последнего приличное количество нововведений — например, параллельное выполнение нескольких запросов к серверу. HTTPS (наверняка слышали) является просто расширением HTTP для безопасной передачи данных. Всё, что мы будем обсуждать в этой статье относительно этой самой передачи, будет работать именно с HTTP.
• FTP используется исключительно для передачи файлов. Когда админ что-то заливает на сервер, он часто делает это именно по FTP (или по FTPS — расширению FTP, заточенным на безопасность).
• SSH — тоже протокол, но используется для доступа к серверу. Сам по себе является защищённым, позволяет выполнять команды и вообще управлять операционной системой на удалённой машине. Ваш админ 100% юзает SSH.
• SMTP, POP3 и IMAP — протоколы получения и отправки электропочты. Мы вообще о них не будем говорить. Гляньте в свой почтовый клиент, там вы найдёте именно их.

Особенно редкие или сложные случаи, а также всякие надстройки, специализированные протоколы и пакеты протоколов, мы рассматривать не будем. Если интересно, загуглите TCP/IP, SOAP, TELNET.

Форматы и структуры

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

Способов структурирования обмена данными лютая тьма. Но в этом цикле про data design мы говорим преимущественно про мобильную и веб-разработку — а в ней почти всегда используется именно API. Чуть дальше я расскажу об этом подробнее.

Запросы: общая схема

Чтобы у вас не сформировалось впечатление, будто весь веб работает исключительно на апишках, разъясню один нюанс. Представьте, что у вас есть сайт. Он может работать по двум схемам: делать запросы к серверу последовательно, по мере загрузки (просмотра) страницы или перехода пользователя от блока к блоку; или же грузить всю страницу сразу, за один запрос. Зависит это, конечно, от технологии, которая была выбрана при реализации, — но выбор ее, в свою очередь, уже зависит от бизнес-требований и, собственно, дизайна данных. Например, gmail.com используется первый вариант, а medium.com — второй.

Так вот во втором случае использовать API не нужно. Весь контент грузится сразу, за один присест. Перешли к новому посту — страница обновилась, выполнился новый запрос. А вот в случае со SPA (Single Page Application, коим является тот же gmail) — последовательно выполняется множество запросов, в зависимости от действий пользователя. Часто второй способ (medium.com) называют синхронной передачей данных, а первый (gmail.com) — асинхронной.

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

Большинство сайтов не работает на основе API — банально потому что так проще и дешевле. А вот большинство мобильных приложений — наоборот, целиком построены на взаимодействии с сервером посредством именно API. Продиктовано это, в первую очередь, технологиями. Например, тот же PHP может совмещать в себе логику и представление — то есть в одном файле на сервере производить манипуляции с данными, тут же превращать это в HTML и отдавать браузеру (хотя, признаться, это не очень хорошая практика). В случае с мобильным приложением так не получится: всё представление целиком лежит на клиенте, а логика ограничена только манипуляциями с информацией, полученной от сервера.

Конечно, частенько встречаются исключения. Если эта тема вам интересна, начните с изучения MVC и аналогов.

Запросы: реальность

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

То есть запросы веб-страницы делятся на несколько типов. Вот основные:

• document — основной запрос, в ходе которого получается разметка страницы, а также указание на то, какие еще файлы нужно получить и запросы выполнить;
• stylesheet — таблицы стилей (CSS), которые отвечают за внешний вид элементов на странице;
• script или javascript — файлы JavaScript, регулирующие логику страницы (чаще всего именно они инициируют дальнейшую асинхронную загрузку);
• jpeg или png или gif или svg+xml и прочие — изображения, растровые и векторные;
• font — файлы со шрифтами, которые используются на странице;
• text/html — собственно, HTML, который потом может быть встроен в разметку;
• xhr — асинхронные запросы, те самые, которые обращаются к серверу, не требуя перезагрузки страницы.

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

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

Типы данных

Весь data design состоит из «атомов» — самых базовых единиц информации. Это самый глубокий слой, до которого вам предстоит дойти: научиться не только описывать логику, конкретные запросы и параметры, но и понимать, какими свойствами обладает информация, как её нужно валидировать. Одинаковые с точки зрения логики данные могут быть абсолютно различными в глазах разработчиков. К примеру: обычная цифра 5 является числом ровно до тех пор, пока вы не обернете её в кавычки. После этого она уже становится строкой. А если вы описываете структуру API, то такую ошибку допустить проще простого.

Любые данные делятся на типы: начиная от переменных в коде и заканчивая параметрами, передаваемыми по API. Я постарался собрать самые простые и наиболее часто встречающиеся типы в одном месте — однако важно понимать, что типизация очень сильно зависит от конкретного языка или платформы. Например, для обычных текстовых строк в JavaScript предусмотрен один тип, а в MySQL — целых шесть. Поэтому перед началом работы крайне рекомендую проконсультироваться с разработкой или тщательно прогуглить предметную область.

Строки

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

Наиболее употребимые обозначения строк: string, varchar, text.

Пример сроки:

"Дизайнил-дизайнил, да не выдезайнил"

Числа

Чаще всего делятся на целые и с плавающей точкой. Например, для обозначения целых чисел в разных языках используются number, int, integer. Тип чисел с плавающей точкой чаще всего называется float или double.

Пример целого числа:

79

Пример числа с плавающей точкой:

34.98

Дата и время

Чаще всего используется именно в базах данных. В языках программирования зачастую (да и в том же API) представлен или числом, или строкой. Я объединил здесь дату и время, но они могут быть представлены и по отдельности. Форматы их довольно сильно отличаются, приведу примеры из MySQL.

Пример даты, тип date:

2019-03-19

Пример времени, тип time:

23:48:37

Пример даты и времени, тип datetime:

2019-03-19 23:48:37

Пример числовой записи даты и времени (количество секунд, прошедшее с 00:00:00 UTC 1 января, 1970 года), тип timestamp:

1553028517000 

Логический тип

Самый простой тип, используемый в языках программирования. Может содержать только два значения: правду (true) или ложь (false). При этом очень часто true может быть заменено единицей, а false — нулём. Например, тот же MySQL не поддерживает логического типа в чистом виде, его тут заменяет tinyint (самое маленькое число), принимающий значение 0 или 1. Чаще всего для обозначения логического типа данных используются обозначения bool или boolean.

Пример булева значения:

true

Массив

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

Пример массива:

["яблоко", "ананас", "груша"]

И еще, более сложный (иногда такой называется объектом или словарём — в зависимости от языка и контекста).

{
   name: "Василий",
   surname: "Иванов",
   year: 1980
}  

Выдохнули

На этом вводная в матчасть закончена. Дальше будем говорить про БД, API и прототипирование всего этого дела. Если, конечно, у вас хватит сил — я очень хорошо понимаю, что для дизайнеров, пришедших в профессию из графики, всё это реально тёмный лес. Что ж, давайте его освещать.

Запись Дизайн данных (часть 4). Матчасть: основы. первой появилась на Павел Шерер.

Освежаем память

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

Среди архитектурных компонентов мы рассматриваем только мобильное приложение и сервер (middleware). Нам не важно, откуда берутся данные о миграции (админка ли это, внешняя интеграция — плевать). Также мы не станем описывать запросы к сервису СМС-рассылок, которые будут генерить необходимый для регистрации код. Наша задача — научиться в data design, а не спроектировать полноценный сервис.

Базовая структура данных приложения выглядит вот так:

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

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

Страшное слово API

Вполне вероятно, что сейчас я не открою никому Америки, но, все же: API — это интерфейс обмена данными. Но не тот интерфейс, что на экране. Программный интерфейс: набор методов, с помощью которых сервер и мобильное приложение/сайт сообщают друг другу, что делать. Конечно, реальное использование API куда шире этого (взять те же IoT-устройства), однако нам пока хватит рассмотрения web и mobile.

На самом деле, в большинстве «апишек» нет ничего сложного — при условии, что они хорошо документированы; а дизайнер, изучающий их, малость прошарен в технической стороне вопроса.

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

Разумеется, я не стану погружать вас в пучину кодинга и рассказывать о сигнатурах, функциях, классах. Мы обойдем даже такие популярные темы, как REST и «физические» случаи, вроде Keyboard API. Особо упорные могут копнуть эти темы самостоятельно — или же дождаться следующих постов цикла про дизайн данных.

Методы

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

Даже вот так проще: каждый запрос на сервер содержит в себе метод, в котором описывается, какие именно данные нужно получить. Если у метода есть параметры — они тоже указываются в запросе. И ещё кое-что, но об этом ниже.

Важный момент: не путайте методы API и HTTP-методы.

Как правило, каждая отдельная операция имеет свой собственный метод. В нашем приложении методами API будут:

• регистрация/аутентификация;
• подтверждение номера телефона (код из СМС);
• получение списка точек;

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

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

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

Иногда название метода API зашивается в адрес (например, https://<...>/points/get/), иногда — указывается прямо рядом с параметрами запроса, а порой даже эти два способа комбинируются. Мы, чтобы не усложнять, будет рассматривать только второй вариант.

Параметры

Здесь все просто. Именно в параметрах мы указываем дополнительную информацию для сервера. Как правило, параметр имеет пару «ключ: значение». Например, «name: Вася», где «name» — это ключ, а «Вася» — значение.

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

Если вы внимательно читали предыдущую статью, то должны помнить, что свойства сущностей могут быть сложными, включающими в себя несколько значение. С параметрами этот фокус тоже работает — вы можете указать внутри одного ключа ещё несколько пар «ключ: значение».

Заголовки

Это такая магическая штука, которая позволяет нам не дублировать одну и ту же информацию в каждом методе.

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

Мы можем, конечно, каждому методу добавить дополнительные параметры, за это отвечающие. А также версию приложения, платформу и тьму прочих данных. Представляете, как распухает каждый метод? У нас пойдет дублирование — и если потом мы решим, что для аналитики нам нужно с каждым запросом передавать ещё что-то… Да, придется переписывать все методы как на сервере, так и на клиенте. Не очень удобно, дорого и ненадежно.

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

Ошибки

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

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

В двух словах об этом не рассказать. На текущем этапе будет достаточно, если вы просто будете знать, что ошибки нужно делить на типы (например, «ошибки получения данных», «ошибки авторизации» и тп), и внутри каждого типа создавать список кодов каждой ошибки (например, «неверный код из СМС», «пользователь не найден», «секретный ключ устарел» и так далее). Разумеется, приложение должно уметь работать с каждым типом и кодом. И чем более универсально — тем лучше.

Схема

Итого, очень упрощенная схема запросов (requests) и ответов (responses) выглядит так:

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

Запросы к тюленям

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

Структура запросов

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

В нашем случае каждый раз мы будем передавать:

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

Поэтому эти данные мы вынесем в заголовки. Всё остальное пускай отправляется в теле запроса.

Вот так у нас будет выглядеть первый набросок схемы запросов к API:

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

Регистрация и аутентификация

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

1. Со стороны нашего сервера к внешнему сервису СМС-рассылок отправляется запрос на формирование кода, сервис возвращает этот код. Эту часть детально описывать не будем.
2. Сервер ищет в БД пользователя с указанным номером телефона.
3. Если пользователь не найден:
   1. Формируются два идентификатора пользователя:
      • внутренний (для собственных нужд);
      • глобальный (для общения с миром).
   2. В базу данных на сервере записывается:
      • полученный номер телефона;
      • код, который вернул сервис;
      • дата и время регистрации;
      • внутренний идентификатор;
      • глобальный идентификатор.
4. Если пользователь найден в БД по номеру телефона, то на этом шаге мы просто обновляем ему код, который нам вернул СМС-сервис.
5. В мобильное приложение возвращается информация о том, что «всё хорошо, жди кода в СМС» (статус) и глобальный идентификатор пользователя. В случае ошибок (например, СМС-сервис вдруг сдох), мы возвращаем в приложение соответствующее сообщение.

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

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

Добавляем первый метод в схемку, указывая единственный параметр, который в него передаем:

Подтверждение номера телефона

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

Далее, на сервере:

1. Осуществляется поиск в БД по полученному идентификатору пользователя.
2. Если пользователь не найден, на клиент возвращается сообщение об ошибке.
3. Если пользователь найден, полученный код сверяется с записанным в БД.
   1. Если коды не совпадают, в приложение снова улетает ошибка.
   2. Если коды совпадают:
      1. Формируется секретный ключ.
      2. В базу данных записывается сформированный только что ключ и полученный идентификатор устройства. Причем записываются они в связке, взаимозависимыми.
4. В мобильное приложение возвращается сообщение о том, что «всё ok» и секретный ключ.

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

На этапе формирования запроса у нас еще нет секретного ключа, поэтому в запросе соответствующий заголовок остается пустым.

Всё, вроде, просто — но только если вы понимаете общую структуру данных. Будь наш пример чуть сложнее, то на уровне чистого (незамутненного техническими заморочками) юикса можно было бы нагородить такие костыли, что бедные разработчики потом умывались бы кровавым потом. Или напротив, сделали бы «по-своему», со всеми вытекающими.

В любом случае, метод и параметр улетели в общую схемку:

Получение списка точек

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

Авторизация

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

Итак, для авторизации мы в заголовках запроса передаем секретный ключ. Включаем paranoiac mode и (как уже решили выше) добавляем к запросам уникальный идентификатор устройства. Как мы помним, они у нас связаны на сервере — как раз для того, чтобы секретным ключом не могли воспользоваться с другого девайса плохие дяди.

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

Инициализация

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

Также при инициализации может происходить проверка на устаревшие данные (например, профиля) для обновления кэша. Или проверять статус синхронизации состояний, если ваш продукт поддерживает бесшовное взаимодействие.

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

Собственно, получение точек

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

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

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

1. Если пользователь найден, секретный ключ, полученный в запросе, сравнивается с аналогом в БД у пользователя:
   1. Если ключи совпадают, проверяется соответствие идентификатора устройства из запроса с сохраненным в БД (и связанным с секретным ключом):
      1. Если идентификаторы не совпадают, сервер формирует ответ с ошибкой и отправляет его в мобильное приложение.
      2. И только если идентификаторы устройств совпадают, происходит формирование списка точек: осуществляется запрос к БД, в котором в качестве параметров указываются отступ (по факту, количество дней от начала, которые надо пропустить) и область видимости (просто количество дней, за которые нужно получить данные). Полученный массив, вместе со статусом «всё ok», отправляется на клиент.
   2. Если ключи не совпадают, сервер прерывает операцию и сообщает об этом мобильному приложению.
2. Если пользователь не найден, сервер возвращает сообщение об ошибке.

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

Точки приходят нам простым списком, отсортированные по времени. Мы обрабатываем их и «пакуем» по дням, чтобы нормально отобразить в интерфейсе. Всё.

Вот наша финальная схемка запросов:

К слову об ошибках. Посмотрите, сколько в сценарии выше их может возникнуть. Целых 4 штуки, не считая технических (типа «сервер упал», «нет интернета» и тп). А в мобильном приложении каждую из них нужно грамотно обработать и показать пользователю. И это суперпростой пример.

Оптимизация — сестра UX

Готово, обмен совершен. Всё работает, пользователь доволен. Но давайте малость отмотаем назад, до регистрации/аутентификации. Не кажется, что можно что-то оптимизнуть? Вот у нас прошел запрос на подтверждение номера телефона, мы получили секретный ключ — и выполняем новый запрос, на получение точек. Зачем? Что будет видеть пользователь всё то время, пока выполняются два запроса подряд? Лоадер, заглушку, плейсхолдеры?

Ведь мы знаем, что после успешных регистрации или аутентификации всегда показывается экран со списком точек. Что будет, если в параметры запроса с кодом из СМС мы сразу включим отступ и область видимости? О да, мы сделаем на один запрос меньше, а наш горячо любимый юзер получит результат на секунду-две раньше. Если хотите, попробуйте расписать сценарий обмена данными с учетом этого — простенькое упражнение, но оно гарантирует, что посыл этой статьи выветрится у вас из памяти несколько позже.

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

Колдунство

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

Что дальше?

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

Запись Дизайн данных (часть 3). Меняемся? первой появилась на Павел Шерер.