Уже нет… 😅

📌 GET в REST API

Всем привет! Начинам разбирать следующий фундаментальный HTTP-метод в REST — это GET.

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


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

🟢Вы хотите получить доступ и прочитать информацию, не изменяя её.
🟢Вы хотите получить представление ресурса - информацию о конкретном объекте из БД.
🟢Вы хотите получить представление коллекции ресурсов - список объектов.


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

❌Для добавления нового ресурса: GET не предназначен для создания новых записей. Для этого лучше подходит метод POST. Также стоит помнить, что GET не поддерживает Body, что является второй проблемой для его использования на создание запросов.

❌Для модификации ресурса: Если цель — обновить существующий ресурс, GET не подойдет. Вместо этого стоит использовать PUT или PATCH.

❌Для удаления данных: Для этой задачи предназначен метод DELETE.

❌При необходимости передать на вход в запрос большое количество данных или конфиденциальную информацию: всё, что передаётся с помощью GET, отображается в URL - query-параметры после ?, что может создать проблемы с безопасностью и длиной URL.


Что еще важно знать:
При работе со списками в query-параметрах запроса рекомендуется использовать элементы пагинации - постраничное отображение данных (limit, offset, count).

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

📌 GET в REST API: Основные рекомендации при проектировании


🌟 URL ресурса при GET:

При использовании GET URL чаще всего указывает на конкретный ресурс или коллекцию ресурсов. URL может включать идентификаторы, путь или query-параметры для фильтрации.

GET https://tms.com/api/v1/tasks - получить список всех задач.
GET https://tms.com/api/v1/tasks/{taskId} - получить детали задачи с идентификатором {taskId}.
GET https://tms.com/api/v1/users/{userId}/tasks - получить все задачи пользователя с идентификатором {userId}.
GET https://tms.com/api/v1/tasks?status=open - получить все открытые задачи, где status - query-параметр.

*{userId} и {taskId} - указатели на конкретные объекты данных в БД по их уникальным id. Пример для id задачи = 123: GET https://tms.com/api/v1/tasks/123.


🌟 Тело запроса GET:
Тело запроса при использовании GET не передается.
Всю необходимую информацию мы передаем в URL - query-параметры (фильтры, сортировка, пагинация).


🌟 Ответ на GET-запрос:
При успешном выполнении GET-запроса возвращается статус 200 (OK) с запрошенными данными. Если ресурс не найден, должен возвращаться статус 404 (Not Found). В случае ошибки на стороне сервера — 500 (Internal Server Error). И другие ошибки.


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

В среду на практическом вебинаре в онлайн будем вместе работать с инструментом тестирования API - Postman. Я расскажу зачем и когда он нужен системным и бизнес-аналитикам.

Показывать интересные фишки буду в прямом эфире! Важно будет выполнять задания вместе со мной 😉

Поэтому, пожалуйста, подготовьтесь к эфиру!

☑️ Зарегистрируйте аккаунт в Postman, на сайте https://www.postman.com/. Дополнительно можно скачать и установить официальное приложение.
☑️ Работать на вебинаре с компьютера.
☑️ Заранее подготовить вопросы по проектированию REST API, на которые я смогу ответить онлайн. Могут быть связаны с постами в канале.

Практический вебинар:

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

До встречи ❤️

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


🟢 Описание метода:
Метод GET /task для получения списка задач. Он позволит пользователям системы просматривать задачи на основе различных критериев (например, статус, исполнитель) и упорядочивать их по определенному параметру (например, дата создания).

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

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

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

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

4. Полученные результаты сортируются согласно указанным в запросе параметрам сортировки.

5. Сервер возвращает отфильтрованный и отсортированный список задач.

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


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

Запрос:

URL: GET https://tms.com/api/v1/tasks
*Вариант GET …/task тоже допустим, зависит от проекта и договоренностей, которые определите в команде.

Query-параметры:
- status (опционально) — статус задач ("open", "closed" и т.д.).
- assignedTo (опционально) — id исполнителя задачи.
- order (опционально) — параметр сортировки, пример использования: createdAt;desk (сортировка по дате создания задачи, desk - по убыванию).

Ответ:
Статус: HTTP-200 OK.

Тело ответа (Body):
Массив задач, соответствующих указанным критериям.
[
{
"id": 1,
"name": "Оформить документы",
"status": "open",
"assignedTo": "123",
"createdAt": "2023-10-17"
},
{
"id": 2,
"name": "Проанализировать отчет",
"status": "closed",
"assignedTo": "124",
"createdAt": "2023-10-16"
}
]

--------

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

Влияние на БД выполнения метода 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 — это комьюнити единомышленников, которое всегда поддержит, если становится трудно и опускаются руки ❤