Серия «Карьера в IT. Системный аналитик.»

1. Архитектурно-интеграционные вопросы:

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

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

   3. Что такое REST? Какие основные принципы у него есть? Какие методы есть в REST? В чем разница между GET и POST запросом?

   4. В каких местах (четырех) мы можем передать атрибуты в запросе? (Path, Body, Query, Header).

   5. Что вы знаете про концепцию CRUD?

   6. Что такое идемпотентность? Какие методы являются идемпотентными?

   7. Что такое синхронные и асинхронные интеграции? В чем между ними разницы? С помощью чего можно их реализовать?

   8. Можно ли реализовать асинхронную интеграцию через REST? (Вряд ли этот вопрос будут задавать, если вы не ответите на предыдущие. Это скорее со звездочкой и не обязательный)

   9. Что такое очередь сообщений? Как передаются сообщения через очередь? Какие очереди сообщений есть и в чем между ними разница? (Если расскажете про PUSH/PULL-стратегии - плюсик в карму обеспечен)

   10. Что такое гарантированная доставка сообщений и какими механизмами ее можно обеспечить?

   11. Какие вообще способы интеграции существуют? С какими из них приходилось работать? В чем их преимущества и недостатки? (Интеграция через обмен файлами, через общую БД, через веб-сервисы и обмен сообщениями)

2. Базы данных:

   1. Что такое базы данных? Какими они бывают? С каким БД приходилось работать?

   2. Что такое ER-диаграммы? Приходилось ли их проектировать?

   3. На какой уровень оцениваете свой уровень владения SQL? С какими инструментами по работе с БД знакомы?

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

3. Различные задачки:

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

4. Небольшие оффтопные вопросы:

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

   2. Чем верификация отличается от валидации?

   3. Приходилось ли работать с JIRA\Confluence?

Конечно, так получается, что если вы знаете ответы на все эти вопросы, или больше 80-90%, то как будто бы вы уже не джун. Но чем лучше вы отвечаете, чем лучше вы соответственно подготовились - тем больше вам зададут вопросов (в нормальном интервью, а не шаблонном). Что очень сильно повысит ваши шансы получить оффер и выделиться среди других кандидатов.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-,хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

• Получать список пользователей целиком или по заданным параметрам фильтрации;

• Открывать карточку пользователя (детальную информацию по нему);

• Редактировать ее по необходимости;

• Удалять пользователя (или физически объект целиком, но это скорее редкость, или просто помечать его удаленным или неактивным);

• Создавать нового пользователя.

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

• GET /users

• GET /users/{userId}

• PUT /users/{userId}

• DELETE /users/{userId}

• POST /users

Т.е. по сути реализуем концепцию CRUD по отношению к ресурсу User.

То, как описать метод GET /users/{userId} мы рассмотрели в прошлый раз, сегодня рассмотрим метод POST /users.

Но для начала расскажу как описывать модель данных системы (один из вариантов того, как это можно сделать), т.к. это тоже важная часть ТЗ (спеки), которую должен делать СА. Разберем просто на примере с комментариями:

Ссылка на конфлю кому нужно, пока он еще работает.

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

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

В рамках данного шаблона есть немного кастомных вещей, свойственных для моих проектов. Например, вот эта вот "Ссылка на userGroup", это означает FK на таблицу на таблицу USER_GROUP и связку с соответствующим объектом. А атрибут role с ссылкой в типе на ref.Roles это enum (справочник). Т.е. атрибут может принимать только одно из значений из списка:

Конкретно эти штуки на разных проектах описываются сильно по-разному, но тут уж у кого как принято. Общий смысл всегда идентичен. В чем плюс этого варианта - ты одновременно описываешь и DTO (структуру данных метода) и структуру данных БД.

С моделью данных разобрались, это нам поможет при описании метода в том числе.

Описание самого метода (ссылка на конфлю):

Обычно методы по созданию объектов сложнее, но тут у нас очень простой процесс, почти нет проверок, поэтому так)

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

И не менее главное - указать правила того, как должны заполняться атрибуты объекта при его создании (маппинг). Чтобы разработчик понял, откуда ему брать эти значения. В данном случае часть полей заполняется константами а остальная часть полей берется из request, т.е. тех данных, которые прислали на вход данному методу.

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

Получился еще более длинный длиннопост, чем обычно. Но вам, вроде бы, не привыкать. Вопросы, комментарии по сабжу - как обычно welcome.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Проработка задачи со стороны заказчика

Всё должно начинаться с ключевого лица в данном процессе - заказчика. Он должен сформулировать постановку задачи и ее цель (хотя бы попытаться). На одном из проектов бизнес-заказчики писали BRD (Business Requirements Document), в котором излагались ключевые требования к задаче, ее экономическое обоснование и различные пожелания к итоговому результату.

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

Бизнес-анализ

Дальше должен идти этап бизнес-анализа задачи, в результате которого должны появится качественные БТ (бизнес-требования), в которых детально описано то, как процесс нужно изменить, чтобы выполнить цели задачи. Как именно это будет описано - уже не важно, хоть через AS IS\TO BE, хоть простым русским языком.

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

Проработка архитектуры

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

Опять же, на одном из проектов был процесс, когда архитекторы системы оценивали КАЖДУЮ задачу и даже если она была небольшой, то не писали больших документов, а прям в JIRA писали краткое архитектурное заключение о том, какие процессы требуется доработать (и это было прям хорошо, заметно снизило количество кросскомандных недоработок).

Системный анализ

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

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

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

Разработка

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

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

Тестирование

А вот тут интересно. Потому что хороший тестировщик не будет ориентироваться только на ТЗ - он еще просмотрит BRD, БТ - сверит то что там написано с тем, что написано в ТЗ, потенциально выявит недостаток требований или их некорректность (было такое на практике) и только потом уже приступит непосредственно к тестированию.

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

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

Заключение

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

Если же проект маленький или просто нет позиций PO\БА\АР и вот этого всего многообразия ролей, то вспоминаем что я говорил в самом начале серии постов про системного аналитика - что это человек, который может совместить в себе все эти роли и обязанности, проделать сбор требований, бизнес-анализ, архитектуру и системный анализ самостоятельно и потом выдать удобоваримое, комплексное ТЗ разработчику. И сначала это даже интересно, сильно прогрессируешь в компетенциях, но только сначала)

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

И нет никаких технических ограничений в принципе. Ты можешь спокойно использовать метод GET для удаления объекта, если ты его так напишешь (не делайте так) или использовать метод PUT, вместо POST, для создания объекта (так уже можно, если понимаешь почему). Главное, чтобы ты понимал как эти тонкости реализации правильно применять. Если сомневаешься - используй методы по классике, хуже от этого он работать не будет.

Да, можно уже прям сейчас кидать тапками.

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

1. Имя endpoint'а - это существительное, а не глагол. Это одна из самых распространенных ошибок, которые я когда либо встречал (и сам совершал, естественно). Например, было в моей практике и такое - POST /generateMultipleDocument.

Тут важно понимать, что метод - это уже глагол и еще раз дублировать его в наименовании эндпоинта не нужно.

В идеале, в данном варианте будет POST /documents

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

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

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

Например, вот так:

/documents

/documents/{documentId}

Вместо:

/document

/document/{documentId}

1.2. Используйте "/" для обозначения иерархии и в принципе используйте вложенность ресурсов.

Например, если мы именуем наш ресурс, как users/{id}/playlists/{id}/songs - это значит у мы хотим работать со всеми песнями, конкретного плейлиста конкретного пользователя. И сразу понятна иерархичность этих ресурсов.

1.3. Не используйте "/" как закрывающий символ вашего URI.

Вариант users/{id}/playlists/{id}/songs сильно лучше, чем users/{id}/playlists/{id}/songs/

1.4. Используйте "-" для разделения составных слов.

Заглавные буквы использовать нельзя, поэтому привычный lowCamelCase нам не подойдет. Если писать всё слитно - очень не читабельно.

Поэтому вместо /applications/{id}/creditcardhistory, куда лучше использовать /applications/{id}/credit-card-history.

2. Не забывайте про версионирование микросервиса. Почти любой сервис с течением времени развивается и обрастает все большим количеством функций. Если сервис при создании получил версию 1.0.0, то при добавлении какой-нибудь логики в него, добавлении нового метода или полного рефакторинга - версия должна измениться.

Например:

host/v2/documents вместо host/v1/documents после внесения мажорной доработки.

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

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

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

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

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

3. Используйте пагинацию.

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

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

4. Используйте коды ответов HTTP правильно и эффективно.
Их достаточно много (https://developer.mozilla.org/ru/docs/Web/HTTP/Status) и их можно использовать по назначению. Все знать и использовать не обязательно, но вот примеры их использования

Использовать 201 "Created", вместо 200 "OK", в случае если вы в POST действительно создаете какой-то ресурс. Используется только в POST (ну и в PUT, в ряде частных случаев).

Использовать 204 "No Content", вместо 200 "OK" для DELETE. Это ответ на успешный запрос и он не будет возвращать тело, что и не нужно для данного метода.

Не забывайте использовать 401 "Unauthorized", 403 "Forbidden" и 404 "Not found" вместо безликого 400 "Bad Request", когда это уместно. Как правило 400 кодом пользуются когда нужно ответить на какую-то ошибку валидации или в случае возникновения бизнесовой ошибки, которую вы заранее можете предсказать (очень настоятельно рекомендую хотя бы дополнять код ответа еще и кодом бизнесовой ошибки в этом случае и желательно ее текстом (error.code и error.message соответственно).

Для валидации желательно тоже).

А для всего остального можно и специальные коды использовать.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Но в большинстве случаев принято что-то среднее между этими крайностями - системному аналитику важно описать следующее:

1. То, какие данные метод получит на вход и правила валидации для них;

2. То, что метод должен сделать с этими данными, т.е. какую бизнес-логику выполнить;

3. То, что метод должен вернуть в ответ вызывающей стороне.

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

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

Если кто хочет посмотреть "вживую" или попользовать шаблон - вот ссылка на страницу моего конфлю (вроде должна работать).

Теперь по шагам:

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

2. URI или URL метода. Состоит из одного из типовых глаголов плюс сам путь, по которому данный метод будет доступен. Про всякие best practices нейминга расскажу отдельно, в комментариях под предыдущим постом спрашивали;

3. Разрешения или Permissions. Если у вас есть ролевая модель и вам нужно разграничить доступ к каким-либо ресурсам среди пользователей с разными ролями - то вступает в дело данная строка таблицы. В ней нужно перечислить те роли, у которых есть доступ до данного метода;

4. Параметры запроса, который должны (или могут) быть переданы на вход данного метода. Т.к. у нас очень простой метод, то у нас их нет. Единственный атрибут в виде идентификатора пользователя ( {id} ) передается напрямую в ссылке. Т.е. пример запроса будет просто выглядеть вот так: GET /users/22 - дай мне пользователя с идентификатором 22.

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

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

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

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

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

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

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

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

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

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

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

И у него есть определенные принципы, которые важно понимать и применять при проектировании системы.

1. Client-Server (клиент-серверная архитектура)

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

2. Stateless. Без состояния

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

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

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

3. Единообразие интерфейса

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

Это достигается через несколько субограничений:

1. Идентификация ресурсов

В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.

Тут важно понимать, что в REST (в идеале, по крайней мере), ресурс может быть только существительным, а не глаголом. Потому что за "глагол", т.е. действие - отвечает конкретный метод.

2. Управление ресурсами через представления

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

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

3. Самодостаточные сообщения

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

4. Кэширование

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

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

Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.

Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.

5. Система слоев

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

Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).

Что-то вроде того:

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

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

P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.

По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.