💫 Открыта запись на практическую программу 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

🔷 Пример задачи на проектировани JSON - массивы [] 🔷

Списки обычно нужны при получении данных. Но иногда и для других операций.

Когда мы работаем со списками, то при проектировании JSON обращаем внимание на следующее:
1. Есть список - нужна или понадобится пагинация (limit, offset, count).

2. Название списка - рекомендуется множественное число ("cars": []).

3. Список содержит меньше элементов, чем полный объект car, поэтому возвращаем необходимый и достаточный минимум в ответе API (всё, что связано с отображаемыми данными на карточках + с фильтрами).

4. Чем меньше вложенных структур у элементов {} внутри списка [], тем лучше. Убирать лишнюю вложенность по воможности.

5. Рекомендуется сохранять структуру одиночного объекта JSON для удобства клиента.


👉 Пример:
Метод получения списка автомобилей

GET https://rentacar-project.com/api/public/v1/cars

Пример JSON для списка:

{ "limit": 10,
  "offset": 0,
  "count": 235,
  "cars": [
 {
   "id": "b3fd9d8c4-8f6a-4e8f-b7e9-2d8f7b9a0d4c",
   "brand": {
     "id": "f4d8e4a6-8f29-4e60-b8c7-3c6a2dbf8c61",
     "name": "Mercedes-Benz"
   },
   "class": {
     "id": "d5a6e4b8-9b7a-4e92-82f6-b3a6f7b8e0c5",
     "name": "Премиум"
   },
   "model": "CLA AMG",
   "publicCode": "10293847",
   "year": 2021,
   "gearbox": "auto",
   "currentRentalOffice": {
     "id": "a3b9f2d4-7b2a-41e5-8b3e-4c7d3f5e8e3b",
     "name": "Москва, Центральная",
     "address": "г. Москва, ул Центральная, 123"
   },
   "rentalTerms": {
     "startDate": "2024-10-24",
     "endDate": "2024-10-27",
     "dailyRate": 8000,
     "totalPrice": 24000
   },
   "pictureId": "e2c4d6e1-8f1e-43a9-8f2e-4d2f7b8e0b5a"
 },

 {
   "id": "d7cc0a8c4-8f6a-4e8f-b7e9-2d8f7b9a0d6d",
   ...
   ...
   ...
   "pictureId": "a3b7a9e1-8f1e-43a9-8f2e-4d2f7b8e0c6d"
 }
  ]
}

#RestApiGA

🤍 Коллеги, спасибо вам за обратную связь 🤍

Каждый раз душа радуется, когда смотрю ответы в период рассылки сертификатов об окончании обучения и вручения подарков для наших самых активных участников занятий ☺️

Это слова, которые вдохновляют развивать GetAnalyst.

Ваши слова ценны для всей команды 🤍

🙌 Разбор тестирования по структуре URL 🙌

(тестирование было в понедельник)

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

✅ https://api.rentacar-project.com/admin/v1.0/cars?status=available - самый подходящий вариант, так как фильтр по статусу верно вынесен в состав query-параметров.

☑️ https://api.rentacar-project.com/admin/v1.0/cars/available - допустимый вариант, но плохо в нем то, что фильтров для списка авто может быть больше, и лучше всегда фильтры отправлять в query (после ?)

❌ https://rentacar-project.com/v1.0/admin/available/cars - ошибочный вариант, т.к. нарушен порядок: available не является объектом, и он почему-то впереди указателя на объект машины “cars”.

❌ https://rentacar-project.com/admin/cars/status/avallable - ошибочный вариант, т.к. сделали странное нагромождение в конструкции пути запроса, чтобы показать, что status=available (доступен)

‼️api.rentacar-project.com - префикс api перенесен в доменное имя, вместо пути. Это допустимо!

2. Какой из следующих URL является правильным примером для получения информации о конкретном автомобиле (id = 123)?

❌ https://rentacar-project.com/api/admin/v1/car/{123} - не должно быть {}, это используется только для обозначения в документации, что на это место надо подставить значение.

☑️ https://rentacar-project.com/api/admin/v1/car?carld=123 - допустимо, но когда получаем информацию о конкретном id, рекомендовано использовать не фильтры, а path-параметры.

✅ https://rentacar-project.com/api/admin/v1/car/123 - идеально, это метод GET /car/{carId}.

❌ https://rentacar-project.com/api/admin/v1/car/{carld=123} - не должно быть {}, как в=и в варианте 1 что-то странное.




3. Какой из следующих URL является некорректным для запроса списка всех автомобилей в системе?

✅ https://api.rentacar-project.com/v1.0/cars?page=2&limit=10 - допустимо, элементы пагинации page (страницы), limit (максимальное число элементов на страницу)

☑️ https://rentacar-project.com/v1.0/car/all - допустимо, хотя так крайне редко делают, часть all можно смело отбросить

☑️ https://api.rentacar-project.com/cars?v=1.0&limit=10 - можно сделать версию query-параметром. Но это такое же плохо сопровождаемое решение, как и версия api в body. Не рекомендуется, но можно. Если не нравится версия в пути, отправьте в headers. На уровне query ее могут потерять, она бросается в глаза и мешает

✅ https://rentacar-project.com/api/v1.0/cars?offset=100&limit=20 - допустимо, элементы пагинации page (номер элемента), limit (максимальное число элементов на страницу)



Продолжение следует 🙂

#RestApiGA