Влияние на БД выполнения метода GET:

⚪ Так как это метод GET, напрямую изменений в БД не происходит.

⚪ Может увеличиться нагрузка на БД при использовании сложных фильтров или при запросе большого объема данных.

⚪ Оптимизация запросов к БД (например, индексы) может потребоваться для обеспечения производительности.

📌 Пример GET в REST API: Проектирование метода REST API "Получение информации о задаче по id"


🟢 Описание метода:

Метод GET /tasks/{taskId} предназначен для получения детальной информации о конкретной задаче. Он предоставляет пользователям возможность просмотреть полную информацию о задаче по её уникальному идентификатору {taskId}.


🟢 Логика работы:

1. Пользователь отправляет запрос на получение информации о задаче, указывая ID этой задачи.
2. Сервер получает запрос и ищет задачу в базе данных с указанным ID={taskId} из JSON.
3. Если задача найдена, сервер возвращает информацию о ней. В противном случае сервер возвращает сообщение об ошибке (например, "Задача не найдена").

Обработка ошибок:
…


🟢 Формат запросов и ответов:

Запрос:
URL: GET https://tms.com/api/v1/tasks/{taskId}
где {taskId} — это уникальный идентификатор задачи.


Успешный ответ:
Статус: HTTP-200 OK.
Тело ответа (Body):
{
"id": 123,
"name": "Задача №1",
"description": "Описание задачи",
"dueDate": "2023-11-01",
"priority": "high",
"status": "open",
"createdAt": "2023-10-16T10:00:00Z"
}

Обработка ошибок:
1. Ответ при отсутствии задачи:
Статус: 404 Not Found.
Тело ответа (Body):
{
"message": "Задача не найдена"
}

2. ...


Влияние на БД:

⚪Так как это метод GET, напрямую изменений в БД не происходит.

⚪В процессе обработки может происходить чтение данных из БД, что может повлиять на производительность при больших объемах данных. Оптимизация запросов (например, использование индексов) может потребоваться для обеспечения производительности.


------------------

Как вы оцениваете свой навык проектирования REST API?

❤️- уверенно
👍- могу только читать
🔥- хочу освоить

📌 Гайд из 5 шагов по созданию API-документации в Postman
с картинками 🖼👨‍🎨

Так понятнее!

Скачайте, сохраните и посмотрите к завтрашнему вебинару, чтобы мы всё успели!
Готовимся как всегда на 2-3 часа практической работы!

#RESTAPI_getanalyst

🌟Открытость в обсуждениях – ключ в развитии ведущих IT-компаний🌟

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

Как же достигаются эти гармонии и взаимопонимания?
🌟 Первый шаг на пути к этому – в команде не должно быть страха задавать вопросы и высказывать своё мнение.

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

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

Мировые лидеры среди IT-компаний, такие как Google, Apple и Netflix, ценят культуру открытости и взаимного обучения. В их корпоративной культуре нет места страху перед "глупыми" вопросами, потому что они понимают: каждый вопрос приводит к новому пониманию, каждое обсуждение – к лучшему решению.

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


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

Практический вебинар:
📚 Как проектировать REST API в Postman: с нуля до работающих методов
📅 25 октября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

До встречи в прямом эфире ❤️

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Как проектировать REST API в Postman: с нуля до работающих методов
⏰ 19:00 - 21:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Доброго утра и дня! Что вчера было? 🔥 3 часа практики!

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

Разобрали:
👉 Что из себя представляет REST API, и как делать дизайн методов.
👉 Эндроинт называть правильно /user или /users.
👉 Практиковались делать JSON-ы в http://jsoneditoronline.com.
👉 Работали с Postman-документацией.
👉 И много других деталей!

Кстати, дополнительные инструменты для JSON:
👉 notepad++
👉 https://www.jetbrains.com/idea/

На выходе с практикума у ребят остались:
🔑 Инструкция по наполнению корпоративного гайда по дизайну REST API.
🔑 Результаты собственной работы с Postman.
🔑 Знания по REST API.
🔑 Опыт!

В конце я рассказала о старте практической программы REST API с 1 ноября, и ближайшие 2 недели будет открыта запись в нашу небольшую команду!

Вау? Вау! Вы крутые! Спасибо за активность во время вебинара и вопросы! 🔥❤️

P.S. Про повторы напишу отдельно.

📌 PATCH в REST API

HTTP-метод PATCH в контексте REST API обычно используется для частичного обновления записи в БД. Это может быть, например, изменение статуса заказа в интернет-магазине, обновление комментария на веб-сайте или добавление новой информации к профилю пользователя.

PATCH применяется, когда:

🟢Требуется обновить часть данных записи, не затрагивая остальные поля. Т.е. для обновления задачи все её поля передавать не надо. Достаточно просто указать её id и новое значение статуса.


Когда НЕ рекомендуется использовать PATCH?

❌Для создания новых ресурсов: Для этой цели лучше использовать метод POST или PUT.

❌Для чтения данных: PATCH не рекомендуется использоваться для извлечения данных. Для этой цели лучше использовать метод GET.

❌Для полного обновления ресурса (записи в БД): Если вы хотите полностью заменить существующий ресурс, лучше использовать метод PUT.


Особенности метода PATCH:

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

🟣Тело запроса PATCH обычно содержит только те поля, которые требуется обновить, что делает его более компактным по сравнению с PUT.

🟣После успешного выполнения запроса PATCH сервер может вернуть статус 200 (OK) если в ответе содержится обновленная запись или 204 (No Content) если ответ не содержит тела, хотя и без тела 200 тоже допустим, как договоритесь в команде и зафиксируете во внутренних корпоративных требованиях к проектированию API.

-----------------------------
👇👇👇

Основные рекомендации при проектировании PATCH:

🌟 URL ресурса в запросе PATCH представляет конкретный ресурс или запись, которую нужно частично обновить.

Примеры:

PATCH https://tms.com/api/v1/tasks/{taskId} - обновить конкретную задачу с {taskId}, любое из её полей (название, описание, приоритет, статус) или сразу несколько.

PATCH https://tms.com/api/v1/users/{userId} - обновить данные пользователя с {userId}, любое из его полей (имя, телефон, почта) или сразу несколько.
Не рекомендуется:

PATCH https://tms.com/api/v1/tasks - не понятно, какую именно задачу следует обновить, хотя id можно передать в body. Всё же более удобное решение, когда id в URL.

PATCH https://tms.com/api/v1/users/{userId}/tasks/{taskId} - обновить задачу для пользователя с идентификатором {userId}. Не самое лучшее решение, т.к. хоть и соблюдена иерархичность, часть с users/{userId} избыточна, т.к. по БД можно определить какому пользователю принадлежит задача.


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

‼️ И очень важное замечание: в требованиях к PATCH укажите разработчику какие поля можно менять, а какие нет.


🌟 При успешном выполнении PATCH-запроса возвращается статус 200 (OK), если в ответе содержится обновленная запись, или 204 (No Content), если ответ не содержит тела. Если запись не найдена, то часто возвращается статус 404 (Not Found). Возможны другие 400-е и 500-е коды ответов, в зависимости от алгоритма метода и требований к обработке ошибок.

Не было возможности подключиться онлайн на практику по проектированию REST API? 🙁Есть возможность поставить вебинар в планы на ближайшие 3 дня!

📚 Как проектировать REST API в Postman: с нуля до работающих методов
📅 27, 28 и 29 октября
🔗 Получить доступ к повтору

Что вас ожидает:
🔍 Проектированием REST API.
🛠 Практическая работа в Postman.
🔄 Связь API с базами данных и другими системами.
🤖 Лайфхаки по созданию дизайна REST API.

🔑 Инструкция по наполнению корпоративного гайда по дизайну REST API.
🔑 Результаты собственной работы с Postman.
🔑 Знания по REST API.
🔑 Опыт!

Регистрируйтесь сейчас, чтобы не пропустить!

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

✖️ Как правильно назвать эндпоинт для получения списка задач пользователя: GET /tasks, GET /task или GET /users/{userId}/tasks?

✖️ Если пользователь хочет отметить задачу как выполненную, делаем ли мы это через PATCH /tasks/{taskId} или PATCH /tasks/{taskId}/status?

✖️ А как насчет прикрепления файла к задаче? POST /task/{taskId}/attachment или другой метод?

✖️ Каким образом передать приоритет задачи в запросе на изменение: через параметр "priority" или через специализированный эндпоинт?

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

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

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

Есть ли похожие гайды по дизайну API у вас в компании? 🤔
Да - 👍 Нужен и задумываетесь о нём - ❤️

🥳 Эта статья на холиварную тему 🥳

Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.

Можно ли сделать в проекте все методы POST? Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)? Можно ли использовать метод POST для получения данных? ...

Холиварные вопросы! Вкусовщина! Давайте разбираться!

🔗 Читать статью на Habr

Не бойтесь кризисов — они неизбежны.
Бойтесь отсутствия роста.

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

У великого тренера Ирины Винер есть поговорка:
«Пока ты стоишь на пьедестале — ты победитель, но как только сошёл с него — ты снова должен доказать кто ты».

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

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

В работе всегда ориентируюсь на одно правило: «насладись успехами, проживи эти моменты и иди дальше».

Сильные специалисты не останавливаются на достигнутом и всегда стремятся к новым знаниям и навыкам! Они понимают, что мир меняется очень быстро, и чтобы оставаться конкурентоспособными, нужно развиваться😎

Если хотите постоянно быть «на волне», то важно постоянно учиться и совершенствоваться.

Не останавливайтесь на том, что уже достигли — узнавайте что-то новое каждый день.

▪️ Читайте книги и статьи,
▪️ Слушайте лекции,
▪️ Участвуйте в конференциях,
▪️ Интересуйтесь работой коллег.

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

И не забывайте полученные знания сразу отрабатывать на практике 😉


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

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


Наталь, Минск, Бизнес-аналитик со стороны заказчика (банк)

Встречала ранее информацию о REST API, в разных источниках она была достаточно противоречива. В курсах Екатерины нашла то, что искала.

Так получилось, что к моменту завершения курса, я получила оффер и меня пригласили на работу системным аналитиком, как я и хотела!) Поставленная цель, связанная с обучением на курсе, была реализована на 100%.

Из инструментом удалось хорошо разобраться с Postman и Swagger. Спасибо Екатерине за то, что она делает!


Максим, Системный аналитик, Екатеринбург

Разобрался со всеми нюансами REST API. Освоил Postman, это было очень интересно и полезно своими руками протестировать на практике.
В целом очень понравилось, что было много практики на вебинарах. Понравился объем и качество теоретического материала, который содержится в модулях.
Екатерина дает много ценной информации, которую так просто не найти. За счет этого курса мне удалось добавить в свое резюме пару очень важных пунктов, которые сразу повысили интерес ко мне.
И в результате удалось сменить работу на ту, что хотел.


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

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

Хочешь узнать больше про системный и бизнес-анализ, будь с нами 😉👌

Подзаряжаемся к началу новой недели!

‼️И не забываем про последний день повтора практического вебинара:

📚 Как проектировать REST API в Postman: с нуля до работающих методов
🔗 Получить доступ к повтору

Как учиться, работать и не сойти с ума от задач?

Если вы проходили какое-либо обучение, то должны помнить это ощущение драйва в начале. Когда несёшься как локомотив зараженный мотивацией на встречу к новым знаниям🚄

Потом проходит несколько дней, неделя, ещё пару недель и топливо в локомотиве начинает испаряться. Кажется тут что-то упустил, там не доработал.

Это нормально!

Учиться взрослому и учиться ребёнку, подростку не равно одно и то же.
У взрослого, помимо учёбы, наслаиваются работа, дом, дети, собака, друзья и прочие факторы, на которые не нажмёшь DELETE.

Учитывая все эти потребности, я НЕ стремлюсь загнать учеников в упряжку обучения. Мне важна включённость в процесс, чтобы хотелось прийти на вебинар, было желание делать домашку и изучать материал 😎

Как я помогаю дойти до конца обучения и разобраться с информацией в процессе?

1️⃣ На начальном этапе нужно сформировать цель.
Доказано: когда есть ощутимая цель — мозгу учиться понятнее и приятнее.

2️⃣ Логично выстраиваю подачу теории, которая наслаивается одна на другую. Хаосу не остаётся места.

3️⃣ Если ученик на курсе с куратором, то второй всегда старается максимально подстроиться под индивидуальный ритм студента. Мы все разные, у каждого разная скорость восприятия. Это важно учитывать.

4️⃣ Я всегда даю положительную обратную связь за хорошие результаты.
Согласитесь, когда нас хвалят и замечают результаты, мы становимся бодрее и хочется достигать большего.

5️⃣ Всегда мотивируем задавать вопросы и участвовать в процессе.
Даже, если порой кажется, что они банальные — лучше спросить.

6️⃣ Живое общение. На проекте мне важно, чтобы сохранялась дружелюбная лёгкая атмосфера.
Я за то, чтобы в общем чате ученики поддерживали друг друга, делись опытом и общими впечатлениями.

7️⃣ Практика. Именно благодаря тому, что студенты отрабатывают все знания на практике, учиться проще и интереснее. Плюс это хорошая мотивация для обновления портфолио.

GetAnalyst — это комьюнити единомышленников, которое всегда поддержит, если становится трудно и опускаются руки ❤

🎃❤️ Всем привет-привет! Хочу начать неделю не с разбора метода PATCH в REST API, а с пожелания хорошего настроения и рассказа про свои выходные. Не так часто делюсь личным, но тут сейчас вся моя публичная жизнь. Почему бы и да?

Я всё еще медленно вкатываюсь в новую жизнь, и это мой второй Halloween в ней. Или даже третий, если считать с университетских времен в Калифорнии.

🎃 Это была моя первая настоящая Halloween-вечеринка! Ура! Красивые костюмы, невероятные декорации. Всё было не просто идеально, а великолепно! Много деталей и атрибутов праздника. Настоящий американский Halloween в частном доме. Танцы, общение, эмоции - живое.

Знаете голливудские фильмы с крутыми вечеринками? Именно так я себя здесь ощущаю. Я в кино! И этот день был подтверждением.

В том году я была на небольшой вечеринке, но это было другое, больше как домашний праздник. В этом году интернациональное "пати" на 50+ человек. Я искренне счастлива и благодарна своей подруге за организацию и приглашение. Спасибо ей за очередной крутой вклад в фильм о моей жизни ❤️

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

Я занимаюсь учебой в выходные, работаю, но всё же стараюсь сейчас стабильно. минимум 1 день в неделю, быть полностью оффлайн. Это важно.

Ну и в течение недели помним о том, что каждый час надо вставать с места и ходить 🙂

Желаю вам хорошей и продуктивной недели! Делитесь в комментариях, как вы провели эти выходные? Отмечали хэллоувин?)

P.S.
Этот блог - наше с вами общее дело в GetAnalyst. Вы тоже его участники и создатели.
❤️ - если хотим начинать понедельники с историй за прошедшую неделю, что делают IT-шники вне работы.
👍 - не обязательно, или даже не желательно.

📌Пример PATCH в REST API
Проектирование метода REST API "Изменение приоритета задачи"

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

Возможные значения приоритетов: minor, major, high, critical, blocker.


🟢 Логика работы (Алгоритм):

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

2. Система валидирует запрос, проверяя наличие задачи с таким ID, права пользователя на выполнение данного действия и полученное значение статуса.

3. После успешной валидации система обновляет значение приоритета в базе данных.

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


Обработка ошибок:
2А. Полученное значение статуса не соответствует справочнику. Вернуть текст ошибки “Неизвестный статус” с кодом HTTP-400.
…


🟢 Формат запросов и ответов:
Запрос: Для изменения приоритета задачи мы будем использовать HTTP-метод PATCH, поскольку он предназначен для частичного обновления ресурса.
PATCH /tasks/123

{
"priority": "critical"
}


Ответ: 👇👇👇👇👇

Ответ: Успешный ответ будет подтверждать, что приоритет был изменен. Система может вернуть обновленный ресурс в ответе.

HTTP-200 OK
Content-Type: application/json
{
"id": 123,
"title": "Задача №1",
"description": "Описание задачи",
"dueDate": "2023-11-01",
"priority": "critical", // обновленный приоритет
"status": "open",
"updatedAt": "2023-10-17T10:00:00Z" // дата обновления
}


И это неполная постановка задачи… 🙂

Вообще-то с помощью PATCH /tasks/123 можно поменять не только её приоритет, но и остальные параметры, такие как название, статус, описание и другие. В URL-метода не заложено слово “приоритет”, поэтому это общий метод на изменение задачи. Описание алгоритма, общее описание метода и список примеров стоит расширить. Так как на вход так же может быть передан объект:

{
"priority": "critical",
"description": "Описание задачи"
}

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