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

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

- Как найти мотивацию, когда кажется, что все сложнее и сложнее идти вперед?
- Как быть продуктивным, а не прокрастинировать 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

📚 Проектирование REST API: открыта запись на специальных условиях 📚

Предстоит менять компанию и выходить за пределы знаний о системе, с которой работали? Планируете работать с Backend, мобильными приложениями? В текущей компании появился новый проект и нужно разобраться с REST API?
Этот пост для вас 🙂

Открыта предзапись на практическую программу:
📚 Дизайн REST API
🗓 Старт 24 июля

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

В течение 2-х месяцев вас ждет:
◽️ 9 онлайн-встреч с опытными системными аналитиками.
◽️ Работа над ОДНИМ проектом в течение всей программы.
◽️ Детальный разбор проектирования RESTful API с нуля: от БД+UI до готовых RESTful API методов.
◽️ Работа с инструментами для тестирования и документирования REST API - 🟠Postman и 🟢Swagger.

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

Самые приятные сообщения в середине прохождения программы:

Был на собеседовании и получил оффер! Спасибо!!! Все что уже изучили пригодилось. Я смог дать несколько вариантов решения задачи и объяснить, почему каждый из них подходит, какие хуже, а какой лучший

Это результаты вашей работы, которыми я восхищаюсь! 🙌

Приглашаем вас присоединиться к новой команде по работе с REST API!

Есть вопросы или не уверены, что эта программа актуальна для вас?
Пишите @getanalyst или заполняйте анкету предзаписи. Мы свяжемся с вами, поможем оценить ваши текущие навыки и ответим на все вопросы!

Интервью - это всегда сложно. Но к нему всегда можно подготовиться!

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

📚 Подготовка к сложному интервью
©️ Алекс Сюй

Наиболее интересные главы:

▫️ Общие принципы прохождения интервью по проектированию IT-систем
▫️ Проектирование хранилища типа «ключ–значение»
▫️ Проектирование системы уведомлений
▫️ Проектирование ленты новостей
▫️ Проектирование YouTube
▫️ Проектирование Google Drive

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

Внутри: архитектурные схемы взаимодействия, картинки, и доступное изложение от автора. Много рекомендаций по дополнительной литературе.
#hwGetAnalyst

💜 Напоминание об очень крутой практике по SQL 💜

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

Потому что по ходу настигло вдохновение и я подготовила:

1. Гайд по разработке собственной тестовой БД с нуля в DBeaver (инструмент для подключения к БД), по готовой ER-диаграмме.
2. Собрала справочник команд в виде PDF-файла, и передам его коллегам после окончания практики для использования в работе и подготовке к собеседованиям.
3. Создала и описала коллекцию на 30+ готовых SQL-запросов: от простых до самых сложных.

+ тестовая БД на которой сегодня будем изучать SQL с нуля, от простого оператора SELECT до LEFT JOIN, будем смотреть как красиво оформлять результаты.
+ набор запросов для закрепления SQL после практики.
+ презентация и набор лайфхаков по ChatGPT, которые покажу в эфире.
Это было по плану и включено в презентацию 😀

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

Полностью практическое занятие, где Вы пишете SQL-запросы, осознаете их сразу на практике и больше не боитесь любых задач на работе и собеседований, потому что у вас есть своё демо-проект, который можете добавить в портфолио 📂

До встречи на практике! 💜

💾 Гайд по созданию JSON + полезные ссылки 💾

JSON - это текстовый формат сообщений для обмена данными в Интернете, в частности через программный интерфейс REST API.

Данные JSON это пары ключ-значение.

Пример:

{
"id": "1df398dd-32bf-474d-a1a5-222851847801",
"name": "Петр",
"email": “petr@mail.ru”
}

Слева в "" всегда ключ, а справа, после : всегда значение.


JSON поддерживает всего несколько типов данных:

✔️ Number (Целые и дробные числа): 12, -3455 или 24.5
✔️ String (Строки): “Строка всегда в кавычках” или “” (пустая строка)
✔️ Boolean (да-нет. флажок, логический тип данных): true или false
✔️ Array (Массив или список): [“элемент 1”, “элемент 2”, “элемент 3”]
✔️ Object (Объект данных, вложенные JSON): { "name": "Иван" }
✔️ null (Пустое значение): null

❗️ Типа данных для даты и времени нет. Для всего, что нужно дополнительно, используются строки и дополнительные международные стандарты, применяемые к ним.


Простота и легкость чтения человеком сделали JSON основным выбором для многих приложений.


JSON используется в REST API, GraphQL, файлах-конфигураций для систем.


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

#RestApiGA

📋 REST API метод для получения списков - POST или GET? 📋

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

Давайте на примере проекта #GetGym разберём вопросы с неоднозначными ответами:

Просмотр списка тренеров через мобильное приложение клиента.

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

❓Какой метод на получение списка выбрать? GET или POST?
Очевидно, что GET! Но… 🙂


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

Метод GET не поддерживает тело для запроса body, то есть JSON в него передать нельзя. Получается, что все фильтры потребуется отправлять через query-параметры запроса.

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

GET https://getgym.com/api-users/v1.0/trainers?name=Вячеслав&location=Central GetGym&....

query-параметры после символа ?


Если для списка тренеров фильтров всего 4 согласно заданию и GET отлично подходит, то что будет, если у вас маркетплейс, в котором на товар может быть 50 фильтров?

Все 50 разных видов фильтров пойдут в URL? 🤔

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

📋 REST API метод для получения списков - POST или GET? 📋

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

Когда необходимо реализовать большое количество фильтров для получения списка, то решение отправлять их все в URL запроса как query-параметры не лучшее, т.к. это делает URL очень длинным. Это может вызвать проблемы с ограничениями на длину URL в некоторых веб-серверах или браузерах.

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


🤯 Вместо этого, можно использовать метод POST для передачи всех этих параметров в теле запроса в формате JSON:

POST https://getgym.com/api-users/v1.0/trainers

  “name”: “Вячеслав”,
  “location”: “Central GetGym”,
  …
}

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

В двух этих примерах результат будет идентичный: тело ответа со списком тренеров, отфильтрованных по заданным параметрам. Для маркетплейса - список товаров.

Но читаемость и удобство использования будет лучше у метода POST.

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

И

того:

1. Если для списка используется до 15-20 фильтров и длина строки выглядит адекватной, то берём для списка метод GET и отправляем фильтры в query-параметры.
2. Если для списка используется 15 и более фильтров, то стоит задуматься об использовании POST и переносе всех фильтров в body (JSON) запроса и не следовать рекомендациям RESTful API.

Для метода получения списка тренеров в #GetGym лучший выбор GET. Но помним, что есть альтернативное решение для этой задачи ☝️

А какие методы у вас используются для получения списков данных на проекте? GET или POST?

#RestApiGa

▶ Элементы пагинации (limit, offset, count) в REST API для работы со списками ▶

Когда мы работаем со списками в REST API, почти всегда рекомендуется использовать элементы пагинации (pagination). Особенно, при запросе данных из таблиц БД с большим количеством строк.

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

Ключевые параметры пагинации (допустимы другие названия):

◽️ limit — максимальное количество записей, которые хотим получить в ответе. Query-параметр.
◽️ offset — смещение, с которого начинается выборка данных. Query-параметр.
◽️ count — общее количество записей по запросу. Возвращается в ответе, в body (JSON), вместе со списком.


Пример получения списка тренеров в #GetGym

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

Этот запрос вернет список всех тренеров. Но что, если тренеров много и нам нужно получать их частями? Вот здесь и пригодятся limit и offset.

Допустим, нам нужно получить по 10 тренеров за раз.

🔸 Первый запрос: получить первые 10 тренеров

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

🔸 Второй запрос: еще 10 тренеров

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

🔸Третий запрос: еще 10 тренеров

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

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



Зачем это нужно? 😎
1. Удобство отображения: Не все данные нужно отображать сразу, особенно если их очень много.
2. Оптимизация: Запросы с меньшим количеством данных обрабатываются быстрее и требуют меньше ресурсов.


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

#RestApiGA

Проектирование REST API - одна из важных задач, которая лежит на плечах команды разработки Backend 💪

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


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

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


Системный аналитик может внести следующий вклад в реализацию задачи по проектированию REST API:

🟢 предоставить информацию о том, какие данные нужны для интеграции систем, и как эти данные должны быть структурированы и переданы в API;
🟢 предложить использовать соответствующие действиям в системе HTTP-методы, такие как GET, POST, PUT и DELETE;
🟢 предложить использовать определенные структуры JSON-объектов для передачи данных в API;
🟢 помочь обеспечить безопасность API, выбрав механизм аутентификации и авторизации;
🟢 документировать API для облегчения взаимодействия между системными аналитиками, тим-лидами и разработчиками;
🟢 тестировать API через Postman, для проверки правильности его работы и соответствия постановке задачи.


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

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