2️⃣0️⃣0️⃣ HTTP-коды ответов в REST API методах 2️⃣0️⃣0️⃣

HTTP-коды ответов являются неотъемлемой частью структуры ответа REST API. Это стандартизированный способ для сервера сообщить клиенту о результате обработки его запроса.

В разработанной мною API-документации Postman для проекта #RentACar описание ошибок - одна из главных частей документации.

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

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

❗️HTTP-коды ответов, которые нужно знать❗️
Картинка прикреплена к посту.
+ Коды успеха 200-204е
+ Коды перенаправления 300-е (используются крайне редко, об их существовании просто надо знать)
+ Коды ошибок клиента 400-404е
+ Коды ошибок сервера 500-504е

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

Например, при возврате пустого списка может использоваться 204 (No Content), или 200 с пустым body, если такое поведение ожидаемо, или 404 Not Found, если отсутствие данных является неожиданным.

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

Понимание и правильное применение HTTP-кодов в REST API — важный навык для любого системного аналитика 🚀

#RestApiGA

Друзья, делитесь, а какие у вас были озарения после стажировки?😎

#GAhahaha

📄 Шаблон постановки задачи на REST API метод 📄

Структура требований для разработчиков Backend, которую можно использовать в Confluence при описании контрактов REST API методов.

1. Название метода
2. Общее описание
3. Алгоритм работы
4. Пример запроса
5. Пример ответа: успех и ошибки
6. Маппинг данных
7. Дополнительные требования

Аналогичную структуру постановки задачи можно реализовать через инструменты документирования и тестирования API - Postman и Swagger.

Подробнее в статье:
🔗Структура постановки задачи на REST API метод

Также по ней очень удобно делать команды к ChatGPT - это Искусственный Интеллект, который как младший системный аналитик помогает в разработке требований и делает половину работы за вас 🙌

#RestApiGA

📚 Что почитать и посмотреть по REST API: подборка материалов от GetAnalyst 📚

У нас много новых участников в сообществе 🙌 И…! Вместо того, чтобы рассказывать о себе, я решила сделать для вас подборку из полезных материалов по проектированию REST API. Так вы лучше узнаете меня - Екатерину Ананьеву - не на словах, а на деле 🙂

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

(В) Связь базы данных и дизайна REST API

(C) Простыми словами про API

(В) Postman: навык тестирования REST API за вечер

(В) Проект “Система для автосервиса” - видео-обучение.
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
3. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса

(C) Postman: Практическое руководство с примером тестирования открытого API

(С) Postman: Практическое руководство с примером тестирования открытого API - 2.0

(П) Вопросы и ответы по REST API: собеседование на СА

(С) Мини-книга с подробным разбором формата сообщений JSON

(В) Собеседование на СА: разбор задачи на асинхронные запросы в REST API

(C) Структура постановки задачи на REST API метод

(П) gRPС vs REST - что выбрать для проекта

(C) Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)

Также вы можете найти у нас мини-обучения по REST API и практическую программу "Дизайн REST API" для опытных аналитиков.

(В) Видео
(П) Подкасты
(С) Статьи

Делитесь с коллегами, особенно с джунами и мидлами СА!
Сохранили? ❤️

#RestApiGA

One more step has been completed 😎 Друзья, отличного воскресенья и крутых новостей на следующей неделе! Всё получится 🙌

🔥📚 7 шаблонов проектирования архитектуры, которые важно понимать СА 📚🔥

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

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

А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.

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

👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно понимать СА.

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

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)

Всю информацию собрала в мини-книгу прикрепленную к посту 📚

Загружайте и сохраняйте в личный архив!

#АрхитектураGA

👀 Архитектура и Инфраструктура: в чем разница? 👀

Архитектура и инфраструктура в системах — это два взаимосвязанных понятия, которые часто могут путать.


🟢 Архитектура - определяет структуру системы и её ключевые компоненты.

Архитектор или ведущий разработчик выбирает, какие модули или сервисы понадобятся, как они будут взаимодействовать, какие технологии и шаблоны будут использованы для реализации и развития системы. Либо говорит, что проект простой и подойдёт монолит 🙂

Всё, что касается:

+ выбора монолитной, сервисной или микросервисной архитектуры,
+ выбора технологий разработки (СУБД, языки программирования, брокеры),
+ выбора API (REST, SOAP, GraphQL и другие),
+ выделение сервисов и микросервисов

,

+ определение количества БД и данных в них,

относится к архитектуре системы.


🟢 Инфраструктура - обеспечивает физическую и виртуальную основу для работы системы.

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

Всё, что касается аппаратного обеспечения:

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

относится к инфраструктуре.

За это отвечают специалисты инфраструктуры (DevOps-инженеры).


Итого:

И архитектура, и инфраструктура помогают обеспечивать нефункциональные требования к системе, как:

◽️ производительность,
◽️ масштабируемость (прирост большого числа пользователей),
◽️ отказоустойчивость,
◽️ надежность,
◽️ безопасность,

но делают они это с разных сторон:

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

👉 Инфраструктура - отвечает за оборудование, на котором эти приложения работают.

#АрхитектураGA

👩‍🌾 Новый проект: микросервисная архитектура для маркетплейса фермеров #FarmFreshGA 👩‍🌾

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


👉 В этом месяце мы проектируем микросервисную архитектуру FarmFresh.


FarmFresh — маркетплейс для локальных фермеров, где можно продавать продукты напрямую покупателям и предлагать подписки на свежие товары.


Основные функции платформы:

✔️ Каталог продуктов — фермеры добавляют товары, а покупатели выбирают и покупают их.
✔️ Подписка на свежие продукты — регулярная доставка с ферм (еженедельно, ежемесячно и т.д.).
✔️ Разовые заказы и просмотр истории покупок.
✔️ Учет остатков и управление доставкой для фермеров с оповещением покупателей о статусах.
✔️ Настройка зон доставки с возможностью указания радиуса и времени.
✔️ Рейтинги и отзывы на продукты.
✔️ Чат поддержки от владельцев маркетплейса для помощи покупателям и фермерам.
✔️ Маркетинговые инструменты: купоны на скидки, акции на товары.

Для пользователей будут разработаны приложения на iOS, Android и Web. Для фермеров также. А панель администратора поможет тех. поддержке управлять всей системой.


📋 План работы:

1. Наглядно разобрать отличия в видах архитектуры: монолит, сервисы и микросервисы.
2. Выделить ключевые микросервисы.
3. Определить API (REST, gRPC, GraphQL и другие) для проекта.
4. Познакомиться с асинхронным взаимодействием и брокерами.
5. Создать схему архитектуры в нотации C4.


Чтобы участвовать в проекте, нужно просто быть подписанным на канал и следить за обновлениями 🙂

Добро пожаловать в новый проект! 🚀

#АрхитектураGA #FarmFreshGA

🍏 Что такое компоненты системы и как показать его на схеме архитектуры? 🍏

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

В качестве интерфейсов могут выступать UI (User Interface) или API (Application Programming Interface).

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

➕ Frontend / UI - приложения с пользовательским интерфейсом.
> iOS, Android и Web FarmFresh для покупателя (3 отдельных компонента)
> iOS, Android и Web FFFermer для фермеров
> Admin FarmFresh - приложение для администраторов и сотрудников маркетплейса


➕ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие компоненты.
> Сервис каталога товаров с его REST API, по которому с ним будут взаимодействовать для получения списка товаров, их поиска
> Сервис платежей с его REST API, по которому с ним будут взаимодействовать сервисы заказов и подписок

➕ БД - базы данных, такие как PostgreSQL, Oracle и ФХ - файловые хранилища.
> БД сервиса каталога с товарами, PostgreSQL
> ФХ для хранения картинок товаров.

➕Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
> Очередь для обработки запросов на рассылку SMS-уведомлений, RabbitMQ


Компоненты выделяют в процессе проектирования архитектуры систем и отражают на схеме архитектуры.


Схема архитектуры может быть визуализирована в:

✔️Геометрические фигуры (прямоугольники, стрелки, облака, своим студентам даю спец. нотацию CR, которую можно использовать в их проектах).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - очень связана с бизнес-контекстом.

Другие нотации моделирования можно посмотреть в этой статье.


В рамках дальнейшей работы над проектом FarmFresh мы будем использовать нотации CR и C4.

#АрхитектураGA #FarmFreshGA

📚 Подборка книг про архитектуру и микросервисы 📚

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

📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс

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

Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.


В дополнение к ней я бы хотела порекомендовать:

📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)

📚 Создание микросервисов, Сэм Ньюмен

📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон

📚 Высконагруженные приложения, Мартин Клеппман

📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин

📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа

📚 DDD - предметно ориентированное проектирование, Влад Хононов

Новогодние каникулы скоро, будет время на полезное чтение 🎄

Сохраняйте подборку и делитесь другими крутыми книгами для системных аналитиков в комментариях! 🙂

#АрхитектураGA

☑️✅ Нефункциональные требования: зачем они нужны? ☑️✅

Когда аналитиков знакомят с нефункциональными требованиями (НФТ), то дают примерно следующее:

НФТ — это характеристики системы, которые описывают её качества и ограничения, но не функции и поведение.

НФТ определяют КАК система должна работать, включая производительность, безопасность, масштабируемость, удобство использования и т.д.

Основная цель НФТ — обеспечить определённый уровень качества системы, соответствовать ожиданиям по доступности и скорости работы.

Но никто не объясняет, как потом эти НФТ реализуются в системе. Какие строки кода их обеспечивают!? 👀


Максимум, который для меня был понятен на старте карьеры:
+ наверное, нужны сервера мощнее,
+ персональные данные как-то шифровать будут.
Всё 🥲

Писали их, как мне казалось, для галочки.
Архитекторов у нас не было. Делали монолиты и прекрасно сдавали проекты. Всё работало быстро!

Так что я научилась собирать и описывать НФТ. А вот КАК их реально используют, удалось узнать только на 4-й год в аналитике 😬

Оказалось, если у тебя большой и высоконагруженный IT-продукт, то нефункциональное требование “Должно выдерживать нагрузку до 10 000 пользователей, работающих параллельно” реально что-то значит.

Нефункциональные требования влияют на:

✅ Архитектуру системы:
+ Выделение высоконагруженных функций в сервисы и микросервисы.
+ Использование способов обмена данными между частями системы, которые не будут вызывать промедлений. Например, gRPC API для взаимодействия микросервисов.
+ Выделение конфиденциальных данных в отдельные БД.

✅ Инфраструктуру системы:
+ Запуск нескольких параллельно работающих копий Backend-приложений, БД и ФХ для обеспечения высоких нагрузок.
+ Защита конфиденциальных данных с использованием специального оборудования.
+ Настройка логирования и мониторинга.

Покажу вам примеры в формате:
требование -> влияние на архитектуру!

А пока делюсь подкастом:
🎧 Нефункциональные требования

Статья к этому эпизоду может стать вашим ЧЕК-ЛИСТОМ при разработке НФТ 🤝

#АрхитектураGA

Был такой период, когда было популярно искать своё предназначение — то самое дело, которое будет зажигать и приносить удовольствие. Кажется, это продолжается и сейчас 🤔

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

Конечно, работа на первом месте. Мы стремимся найти её не только как источник хорошего дохода, но и как возможность для самореализации, радости и вдохновения. Это же 40+ из 168 часов в неделю!

Но хобби тоже может стать не менее заметным и значимым способом самореализации 🙌

Хобби — классный способ перезагрузки вне работы.
Оно помогает:
✔️ отвлечься от повседневных забот,
✔️ не думать о рабочих задачах,
✔️ восстановить энергию,
✔️ вдохновиться на что-то новое.

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

Если бы в жизни была ТОЛЬКО моя любимая работа, и ни на что другое не оставалось места, то... даже звучит как-то грустно. Жизнь многогранная!

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

Хобби - это инструмент защиты от выгорания! 💚🪫🔋

Друзья, только мы сами решаем, как распоряжаться своим временем после работы.
Можно продолжать работать.
Можно лежать и смотреть в потолок.
Можно готовиться к марафону или покупать очередной билет на самолет, чтобы открыть для себя новые места.
Можно всё!
Главное, чтобы это вас перезагружало и заряжало энергией!

Я искренне желаю вам найти то занятие, которое будет вас зажигать, которое будет дарить удовольствие и давать передышку от работы ❤️‍🔥

Делитесь в комментариях, какие у вас хобби? Очень интересно)

🌱 Открыта запись на Архитектуру для системных аналитиков 🌱

Погружение в архитектуру и опыт работы в сложных проектах с микросервисами - точки роста для опытных системных аналитиков уровня Middle+.

Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.

В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks и знакомиться с другими способами асинхронного взаимодействия систем.

Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.


Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷

Приглашаем и вас достигать новые цели вместе с нами! 🙌

🌟 Проектирование архитектуры
🗓 Старт предобучения: 3 декабря 2024
👉 Подробности о программе и запись

🎁 До 25 ноября открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.

Все вопросы можно задать через сайт, на почту info@getanalyst.ru или в Telegram @getanalyst.