💪 Новый проект по REST API: приложение для фитнес-клубов 👟

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

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


Основные возможности, над которыми будем работать:

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

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

🔸 Изменение времени в существующей записи на персональную тренировку.
Изменение времени возможно только на свободные слоты в расписании того же тренера.

P.S. Считаем, что на момент подключения часть проекта уже реализована.


Наши задачи:
1. Познакомиться с основами проектирования REST API.
2. Подробнее описать функции приложения, для которых будем делать REST API методы.
3. Описать архитектуру проекта.
4. Спроектировать часть БД системы под часть проекта, над которой будем работать. И выяснить, почему это важно.
5. Сделать дизайны методов GET, POST и PATCH. Изучить на их примерах:
5.1. Особенности работы с query-параметрами;
5.2. Как строить JSON-ы для запросов и ответов;
5.3. Коды ошибок HTTP.
6. Разобрать маппинг данных и его использование в постановках задач на разработку REST API методов для Backend.

Запускаем июльский проект по REST API? 😉🔥

#RestApiGA

🛠 Внедряем Camunda: краткий обзор и моделирование взаимодействия с использованием BPMN 🛠

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

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

1:07 - Что такое Camunda и чем она может быть полезна для системных и бизнес-аналитиков, разработчиков?
3:24 - Использование Camunda как оркестратора в микросервисной архитектуре. Хореография и оркестрация.
7:43 - Кристина делится опытом использования Camunda для расчетов сумм выплат клиентам.
10:28 - Какова роль нотации моделирования бизнес-процессов BPMN в Camunda. Уровни проектирования BPMN-диаграмм.
16:16 - Нотация BPMN. Можно ли использовать BPMN вместо UML Sequence.
21:09 - DMN как прекрасное дополнение BPMN.
23:01 - Другие инструменты, кроме Camunda Modeler, для создания BPMN-диаграмм.
25:35 - Как использовать Camunda? Обзор решения.
29:38 - Как интегрировать Camunda в действующую систему.
32:08 - Результат внедрения Camunda, личный опыт.
40:55 - С чего начать знакомство с Camunda и нотацией BPMN.
46:40 - Рекомендации по самостоятельному обучению.

Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify

🌟 Ведущая:
Екатерина Ананьева
🌟 Гость:
Кристина Виноградова

Слушайте, подписывайтесь и делитесь с коллегами! 🤝🤍

📚 Подборка книг НЕ про системный анализ 📚

Привет, друзья! Каждый из нас стремится расти, но…. Бывают ситуации, когда нужна помощь и поддержка:

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

Я с этим встречалась и встречаюсь. Мне бывает действительно тяжело, бывают затяжные спринты в переработках, стрессы из-за того, что везде всё валится из рук и не поддается контролю. Но я всегда стараюсь не забывать о главном - жить и радоваться. Иначе зачем это всё?

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

Сегодня я поделюсь с вами подборкой из этих книг:
1. “То, как мы работаем, – не работает. Проверенные способы управления жизненной энергией”, Тони Шварц
2. “В ФОКУСЕ. Твой путь к выдающимся результатам”, Гэри Келлер
3. «Зачем мы спим. Новая наука о сне и сновидениях», Мэттью Уолкер
4. “Атомные привычки. Как приобрести хорошие привычки и избавиться от плохих”, Джеймс Клир
5. “Богатый папа, бедный папа”, Роберт Кийосаки
6. “Путь к себе, или Как изменить жизнь за 21 день”, Марина Маклауд

Рост - это не только про карьеру, но и про ваше состояние 🙌

Сохраняйте подборку и обязательно читайте!
Возможно у вас есть еще ТОП-книги, которыми вы можете поделиться в комментариях - буду рада))

💻 API - что это и зачем? 💻

API (Application Programming Interface - Программный Интерфейс) - это набор правил и протоколов, которые позволяют различным программам взаимодействовать друг с другом.

API разрабатывают в серверной части систем. Поэтому, когда говорят про API, то думаем о Backend-части системы.

Когда я знакомлю с API аналитиков, то всегда сравниваю его с UI (User Interface - Пользовательский Интерфейс), который дает возможность пользователю взаимодействовать с системой с помощью графических элементов в мобильных, веб- и других приложениях. Это Frontend-часть системы.

📚 API vs UI

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

🔘 UI - это про графические элементы и данные, которые он отображает пользователю, через которые позволяет работать с приложением. Данные для отображения обычно берутся от Backend-части системы.

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

Наиболее популярные API в разработке:
1. REST API (более 85% проектов по всему миру)
2. SOAP API
3. gRPC
4. GraphQL
5. WebSocket

В рамках проекта #GetGym мы с вами будем изучать принципы работы и проектирования REST API. Вопросы о нем спрашивают на собеседованиях системных аналитиков, от Junior до Senior позиций. А еще мне нравится то, что хорошо зная и понимая REST API, можно с легкостью освоить остальные виды API и принципы работы с ними, важные для системного аналитика.

#RestApiGA

💻 REST + API = REST API 💻

👉 REST (Representational State Transfer) — это наиболее распространенный АРХИТЕКТУРНЫЙ СТИЛЬ для создания веб-сервисов и API.

Это дизайн, а точнее рекомендации к дизайну API-методов! Подход к тому, как сделать URL-метода, какие методы HTTP использовать для передачи запросов в обработку на сервер, как и в каком формате описывать сообщения.

👉 + API (Application Programming Interface)— это набор правил и протоколов, которые позволяют различным программам взаимодействовать друг с другом.


👉 = REST API — это архитектурный стиль, который определяет, по каким правилам приложения должны обмениваться данными между собой. Для доставки данных на сервер использует протокол HTTP.

Так как REST API это по сути рекомендации к дизайну API-методов, то его не всегда строго придерживаются. Отсюда появились понятия:
+ RESTful API - строго соответствует принципам REST),
+ просто REST API - в целом похож на REST, но есть нюансы.

REST API используется для создания веб-сервисов, мобильных приложений и других IT-решений.

Главная цель REST API - облегчить передачу и управление информацией между разными системами: создавать, читать, изменять, удалять (CRUD). REST API использует для этого стандартные HTTP-методы: GET, POST, PUT, DELETE и другие.

Важно знать и понимать отличия:
🔹 REST API - это архитектурный стиль проектирования взаимодействия приложений, не протокол.
🔹 HTTP - протокол, на основе которого работает REST API; транспорт для доставки запросов на сервер и получения ответов от него.


🔵 Примером приложения, использующего REST API, является сервис видео-встреч Zoom.
Они предоставляют открытую API-документацию, которая позволяет разработчикам создавать ссылки на встречи, удалять их и т.д.

Посмотреть документацию REST API Zoom Meetings можно по этой ссылке 🔗
Специально выбрала для вас раздел, где наглядно показано несколько видов HTTP-методов: GET, POST, DELETE.

#RestApiGA

🟢 Структура REST API метода - как читать и что описывать в задаче разработчику 🟢

Для системного аналитика, который планирует работать с Backend-разработчиками на проекте с REST API (которых более 85% по всему миру), важно понимать структуру.

🟢 Запрос:

1) HTTP-метод
GET, POST, PUT, PATCH, DELETE и другие.

2) URL-адрес метода
Конечный адрес URL (другими словами - эндпоинт запроса), по которому располагается API-метод.
Пример для эндпоина, по которому можно будет управлять данными о тренерах в #GetGym:
https://getgym.com/api-users/v1.0/trainers

3) Параметры запроса (query-parameters)
Указываются, в конце URL, после ?. Обычно используются для фильтров, сортировок и элементов пагинации (постраничное переключение результатов с помощью limit, offset, count) в GET-запросах.
Если их несколько, то разделяются символом & (И). Несколько фильтров в запросе как правило применяются с условием И, т.е. одновременно.
Пример получения списка тренеров с фильтром по имени и сортировкой по А-Я:
…/api-users/v1.0/trainers?name=Федоров&sort=asc

4) Заголовки запроса (Headers)
Заголовки используются для передачи метаинформации между клиентом и сервером, такой как формат данных (Content-Type), часовые пояса, типы устройства с которых идут запросы, токены аутентификации (Authorization), и прочее.
Пример:
Content-Type: application/json

4.1) Авторизация (Authorization)
Один из заголовков. Основные виды авторизации: Basic, JWT, API-KEY, OAuth 2.0 и другие.
Пример для авторизации с Bearer Token:
Authorization: Bearer 013ee8a28e4046ccb0c2113edee1d531
01….d531 - это значение токена (ключа, для подписания запроса).

5) Тело запроса (body)
Тело запроса используется в методах POST, PUT и PATCH для передачи данных на сервер. Данные обычно передаются в формате JSON или XML. Пример тела запроса для создания нового тренера:

{ 
  "name": "Иван Федоров", 
  "specialty": "Силовые тренировки", 
  "experience": 5 
}

#RestApiGA

Продолжение 👇

🟢 Структура REST API метода - как читать и что описывать в задаче разработчику (продолжение) 🟢

Итоговый пример запроса на получение списка тренеров с фильтрацией по имени и сортировкой А-Я по алфавиту:

GET https://getgym.com/api-users/v1.0/trainers?name=Федоров&sort=asc

Authorization: Bearer 013ee8a28e4046ccb0c2113edee1d531
Content-Type: application/json

Запрос описали. Его отправляют на сервер. В результате выполнения, с использованием запрограммированной логики в запросе, сервер возвращает ответ.

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


Ответ на запрос:

1) HTTP-код ответа
Один из типовых кодов ответа, применимых запросов.
Примеры:
HTTP-200 - успешный запрос (без создания новых данных в БД)
HTTP-201 - данные созданы
HTTP-404 - данные по запросу не найдена
HTTP-500 - внутренняя ошибка сервера

2) Тело ответа (body)
Тело ответа обычно содержит данные, запрашиваемые клиентом, или сообщение об ошибке.

Пример ответа для запроса на получение списка тренеров с фильтрацией по имени и сортировкой А-Я по алфавиту, описанного выше:

{
  "trainers": [
 {
   "id": "12345",
   "name": "Смирнов Степан",
   "specialty": "Силовые тренировки",
   "experience": 5
 },
 {
   "id": "67890",
   "name": "Федоров Иван",
   "specialty": "Кардиотренировки",
   "experience": 3
 }
  ]
}

Это базовая структура метода REST API. А как её описывать с нуля и почему методы так строятся - будем разбирать в следующих постах по проекту 🙌

#RestApiGA

🗄 DBeaver и практика SQL-запросов 🗄

Уже в следующий понедельник пройдёт продвинутый практикум по БД и SQL:

🗄 Инструмент DBeaver. Практика SQL-запросов
🗓 15 ИЮЛЯ 2024 (ПН)
🕖 19:00 (Мск)
🔗 Подробности и регистрация

План:
1. Знакомство с инструментом DBeaver. Подключение тестовой БД.
2. О применении SQL аналитиками. Ключевые операторы SQL-запросов.
3. Практика SQL-запросов на получение данных в DBeaver.
4. Использование AI (искусственного интеллекта) в качестве помощника в работе с SQL-запросами.

Практикум подойдёт, если вы:
✔️ Знаете основы проектирования реляционных БД (сущности, связи, кратности между ними)
✔️ Умеете проектировать ER-диаграммы (логический уровень минимум)
✔️ Хотите освоить SQL с нуля на практике за одно занятие
✔️ Научиться упрощать свою жизнь с использованием Искусственного Интеллекта при работе с SQL

Мы работали с БД при проектировании Интеграций, мы будем работать с БД в новом проекте по REST API. Понимание того, как работают SQL-запросы влияет на ваш подход к проектированию алгоритмов и самой схемы БД.

Инструмент DBeaver - основной для системного аналитика. Через него можно подключиться к любой СУБД, в том числе наиболее популярной PostgreSQL.

Этот важный практикум для системных аналитиков, который поможет понять что такое SQL и зачем он на примере работы с реальной базой данных 🙌

Материалы по БД для знакомства и подготовки к онлайн-практикуму по DBeaver + SQL:
🔗 Статья о том, зачем БД аналитику
🔗 Статья о прекрасных возможностях DBeaver
🔗 Обучающее видео "Проектирование БД - логический уровень"

До встречи на практикуме! 😉

🤝 Связь CRUD-модели и методов REST API 🤝

Работая над задачами связанными с определением функциональности, я всегда использую CRUD-модель, которая легко сопоставляется с методами REST API:

C - Create - Создать - POST / PUT
R - Read - Читать / Смотреть / Получить - GET / POST в искл. случаях
U - Update - Изменить - PATCH / PUT
D - Delete - Удалить - DELETE / PATCH в случаях архивации

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

❗️Важно помнить, что эту модель нужно прогнать не только для ОДНОГО объекта, но и для МНОГИХ.
❗️Важно уточнять, кто и когда это будет делать.

Статья по созданию CRUD-модели с подробным разбором примера доступна по этой ссылке.

В работе CRUD помогает мне не упустить функциональные требования из виду, уточнить требования к данным в БД и получить уточняющие вопросы по процессам.

Используйте её, чтобы структурировать процесс работы с функциональными требованиями 🙌

💫 Структура URL запроса в REST API на примере #GetGym 💫

Пример метода:
Получить информацию о тренере по его уникальному идентификатору в системе:

GET https://getgym.com/api-users/v1.0/trainers/{trainerId}

1️⃣ Протокол:
В начале любого URL указывается протокол, используемый для доступа к ресурсам.
В примере это https (HyperText Transfer Protocol Secure), который обеспечивает защищенную передачу данных.


2️⃣ Доменное имя:
getgym.com

3️⃣ Путь (Path):
Путь включает в себя один или несколько сегментов, разделённых слешами (/).

- api - указывает на то, что будет выполнен переход в каталог API сервера. Не обязателен. В данном примере отсутствует.
+ api-users - указывает на конкретный интерфейс API, предназначенный для обычных пользователей системы. Также это могло быть указание на API для администраторов в системе.
+ v1.0 - означает версию API, что важно для поддержки совместимости с предыдущими версиями.

+ trainers - это ресурс, к которому осуществляется доступ, в данном случае “тренеры”.
+ {trainerId} - это параметр в пути URL (path-параметр), указывающий на конкретного тренера по его id в системе. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 1234567).


4️⃣ Query-параметры запроса (Query-parameters):
В приведенном примере параметры запроса не указаны, но они могут быть добавлены после знака вопроса ?.

Пример с query-параметрами:

GET https://getgym.com/api-users/v1.0/trainers?page=2&limit=10

?page=2&limit=10 указывает на запрос второй страницы результатов с 10 результатами на страницу. Это два отдельных query-параметра, которые являются элементами пагинации (постраничного получения данных через API).


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

#RestApiGA #GetGym

🎨 Дизайн UI перед дизайном REST API 🎨

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

В случае приложения для сети фитнес-клубов #GetGym, потребителями API будут мобильные приложения iOS и Android. Они будут визуализировать на экране данные, получаемые через REST API от сервера, а также отправлять их туда для сохранения.

🟢 API создается для потребителей - клиентов API!

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


Рекомендация из моего опыта, чтобы не тормозить разработку:

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

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


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

Что в таких случаях делать? Как избежать переработок? Ждать дизайн UI/UX, либо иметь хорошие коммуникации с дизайнером.

🟢 Также помните, что вы можете проектировать REST API не только для приложений с UI, но и для Интеграций, чтобы к вашей системе подключались другие по API (пример - REST API Zoom Meetings). Либо для внутреннего взаимодействия между сервисами и микросервисами внутри системы. Зависит от проекта 🙂

А пока давайте познакомимся с дизайном #GetGym в Figma 🧙

#RestApiGa

🧙 Зачем нужна БД при проектировании REST API методов 🧙

Еще один важный этап подготовки к проектированию REST API методов - знание схемы БД проекта.

Почему важно уметь читать и дорабатывать БД в процессе проектирования API:

🍰 1. По сути, программный интерфейс, в нашем случае REST API, это “щит” между БД и теми, кто хочет читать и писать данные в неё.

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


🍰 2. Не зная модель данных, мы не знаем что конкретно возможно получить из БД и записать в систему.

Бывают ситуации, когда при постановке задач на REST API мы дополнительно заводим задачи на доработку БД из-за нехватки данных.

При постановке задач на REST API мы описываем маппинг (сопоставление) данных с БД для запросов и ответов методов.


🍰 3. База данных при проектировании API помогает мне учесть все данные, которые надо вернуть пользователю и организовать структуру JSON/XML методов.

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



Очень приятное впечатление создается, когда ты проходишь впервые весь путь от проектирования БД до проектирования REST API методов и их использования в мобильных приложениях. Видишь приложение насквозь.

Для меня это огромное удовольствие понимать каждую мелкую техническую деталь всего проекта! 🥰


Базу данных #GetGym для вас подготовила. Показана только часть, нужная для работы с тренерами и записью на тренировки. Если что-то не учла и чего-то не хватает для UI - будем дорабатывать и добавлять.

Предложения и вопросы по БД, даже самые простые? Пишите в комментарии!


И конечно же сохраняйте к себе пример схемы БД в избранное 👀 Примеры проектов и документации нужны всегда, на любом этапе развития аналитика! 🙌

#RestApiGa

🧙 Связь БД и дизайна REST API 🧙

Коллеги, на предстоящие выходные даю вам задание:
посмотреть обучающее видео по БД + REST API.


Познакомьтесь с ним, чтобы:
1. Еще раз закрепить теорию и примеры по REST API с этой недели на практике.
2. Понять, почему я опубликовала UI и БД сегодня, и как они далее будут использованы в проекте.
3. Получить еще один проект в копилку.


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

Так что со следующей недели начнём проектировать методы REST API, глядя одновременно в требования, UI и БД: разбираем теорию на практике! 💝

#RestApiGa