🤩 Структура методов REST API в одной картинке 🤩

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

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

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

Avito Доставка
ЦИАН

#RestApiGA

🪫 Есть ли этот самый Work&Life balance? 🔋

Я всегда работала очень много. 70-часовая рабочая неделя какое-то время была моей "ненормальной нормой". Всякое бывало. И положительные результаты от этого я тоже вижу. Но…

Может показаться, что чем больше работаешь, тем больше успеваешь, но это ловушка. Рано или поздно понимаешь: так дальше нельзя 😰 Когда ты перерабатываешь, страдает здоровье, и страдает сама работа. Усталость и недосып не проходят бесследно — качество выполнения задач падает, настроение ужасное.

Если я сижу за компьютером 12 часов подряд, это не значит, что я много успеваю и действительно эффективна. Это бывает вынужденно, когда задач перебор. И я ощущаю, как скорость работы моего мозга начинает стремиться к нулю.

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

Что я поняла? 👇
Всякое бывает. И переработки, и учеба. Всё это может увеличивать рабочие дни. Главное, чтобы эти переработки не были ежедневно. И делать полноценные выходные без компьютера.

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

Если ты не ставишь рамки, никто за тебя это не сделает.

Мои лайфхаки по установкам границ в Work&Life balance:
1. Заняла время тренировками каждый день.
2. Прогулки и перерывы каждые 90 минут.
3. Сейчас у меня два полных выходных. Скажу честно - пока это стоит мне распределения 50-60 часов задач в 5 дней. Что бывает тяжело. Но это перепланирование последних месяцев заставляет мой мозг искать решения.
4. Планирую максимум две задачи в день, одну из которых можно не успеть.

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

Берегите себя. Работа — это важно, но выгорание никого до добра не доводило.

В мире, где все вокруг стремятся успеть больше, иногда лучше остановиться и перевести дыхание. И это нормально ❤️

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

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

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

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

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

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

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

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

#RestApiGA

💫 Открыта запись на практическую программу REST API 💫

Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:

+ Знание стандартов REST API (JSON);
+ Опыт проектирования API;
+ Опыт проектирования и документирования REST сервисов (JSON);
+ Понимание принципов работы мобильных приложений;
+ Навык проектирования REST API (описание с использованием OpenAPI Specification);
+ Навык тестирования API Backend (Postman);
+ Знание Swagger для создания REST API документации;

Все эти навыки, в разных формулировках, ожидают от Middle и Senior Cистемных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.


Мы осваиваем их на практике в рамках одного большого проекта на программе:
💻 Дизайн REST API
🗓 Старт 5 ноября


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

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты Системных аналитиков 🛠



👉 В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩
Это самая весомая и “программистская” часть вашего профессионального портфолио.


🗓 До 25 октября:
Запись на специальных условиях с дополнительным обучением по БД в подарок, знания которой понадобятся в ходе работы на проекте.


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

✅ REST API - пошаговый план проектирования методов с нуля + пример ✅

Для проектирования REST API методов рекомендуется использовать пошаговый подход:

0. Выбор сущности — определите, для какой сущности разрабатывается API-метод.

1. Анализ потребностей клиента — выясните, какие данные и функциональность требуются на всех экранах, связанных с сущностью. Это поможет создать универсальный JSON-объект (body), который можно использовать для всех операций CRUD-модели.

2. Сопоставление с БД — проверьте, какие данные уже есть в базе данных, и какие необходимо добавить для реализации метода.

3*. Доработка БД — добавьте недостающие таблицы и поля, если это необходимо.

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

5. Определение доступа — задайте роли пользователей, которым будет доступен API-метод.

6. Алгоритм работы (Use Case) — опишите логику работы метода, включая все возможные ошибки.

7. Проектирование запроса REST API — определите метод (GET, POST и т.д.), URL, заголовки (headers) и тело (body) запроса.

8. Проектирование успешного ответа — укажите HTTP-статус, заголовки и тело ответа.

9. Проектирование ошибок — опишите неуспешные ответы: HTTP-статус, заголовки и тело для каждой ошибки.

* - необязательные пункты, зависят от задачи.

Самые первые и важные шаги - понять потребности клиента и оценить полноту данных в БД. Потому что именно на их основе мы проектируем JSON-структуры данных.


Подготовила для вас мини-книгу с примером применения этой пошаговой инструкции для проекта #RentACar 🙌 Книга прикреплена к посту.

#RestApiGA

🔮 Как найти время на саморазвитие? 🔮

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

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

Что помогает мотивировать себя брать дополнительные задачи на саморазвитие:

1. Чёткое понимание цели
Я всегда думаю, зачем мне это нужно и какой опыт я получу.
Если нет ясной цели, начинать бессмысленно.

2. Планирование времени
Выделяю хотя бы 30 минут в день на обучение, в конкретное время.
Главное — начать. А когда начинаешь, увлекаешься, то можно и растянуть этот процесс.
Слот в календаре очень помогает ставить ✔️ и выполнять задачу.

3. Эксперименты сразу
Если я увидела какую-то интересную статью или обучение, то я стараюсь разбираться сразу.
Да, не всегда получается, но главное — начать. То, что откладываешь "на потом", чаще всего остаётся в далекой неопределённости.

4. Разделение большого на маленькие шаги
Это помогает двигаться постепенно. Маленькие шаги дают ощущение завершённости, а это очень мотивирует.

5. Самостоятельные задачи на саморазвитие лучше планировать на утро. Вечером не сделаю и отложу на потом


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

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

А главное — это приносит настоящее удовольствие, когда ты видишь, что становишься лучше и развиваешься независимо от рутинных рабочих задач и других обязательств 🙌

Не отвлекаемся, проходим мимо, фокус на работе 👩‍💻🧑‍💻🦭

Настроение понедельника 😁

🔷 Пример задачи на проектировани JSON без списков - на что обращать внимание 🔷

Как решала задачу по созданию JSON, если говорить не про собеседование, а про реальную работу:

0️⃣ Доработка БД, т.к. на UI больше данных
Мои дополнительные вводные - БД проекта.
В ней отсутствует часть данных, которые есть в UI: правила аренды, характеристики (двигатель, коробка, кол-во мест и другие).
Новые поля и таблицы надо добавить в БД.
На этом шаге JSON пока не трогаю.


1️⃣ Для этого экрана сделала основным объект “автомобиль” (car)
Перечисляю в JSON данные о нем:
- "id",
- "brand" - вложенный объект с данными из связанной таблицы БД, но можно было и упроситить,
- "class" - аналогично "brand",
- "model",
- licensePlate - есть в БД, доступен для админов, но от обычных пользователей гос. номер авто мы должны скрывать,
- "publicCode" - а вот это дизайнеры не учли, надо сообщить, чтобы добавили,
- "color" - в БД есть, а на UI нет, но поле не секретное, поэтому можно вернуть, если вдруг в будущем оно понадобится,
- "mileage" - на экране показано “< 50 тыс”, а в БД конкрентное число, которое обновляется каждый раз после поездок. В API можем возвращать фактическое число миль, а Frontend-разработчики пусть сами наводят красоту с “< 50 тыс” 🙂
…. и т.д.

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


2️⃣ "rentalRules" и "rentalTerms" - логически сгруппировала данные об условиях аренды в общем и для текущего запроса от пользователя.
От логической группировки можно отказаться, но кажется, что это делает структуру более удобной для чтения.


3️⃣ Рассчеты цен делает алгоритм REST API метода, чтобы не дублировать сложные расчеты в разных Frontend.


Есть ли еще варианты для JSON? Да.

Это один из тех, которые выбрала я, зная БД и UI всех приложений, в которых понадобится аналогичный JSON-объект данных car (автомобиль).


#RestApiGA