🎯 Вижу цель - иду к ней 🎯

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

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

Поэтому, если не хочется через какое-то время оглядываться назад с сожалением, говоря:
"Почему он получил повышение/5 офферов на высокую ЗП, а я нет? 😔",
начните с формирования своего плана развития.


О чем из этого списка хоть раз задумывались? 🙂

◾️Хочется сменить проект, но на текущем месте работы нет возможности получить нужный опыт.
◾️Ничего не знаю тему. Хочу освоить, чтобы меня повысили в моей компании, или искать новую.
◾️Нужно структурировать знания и пополнить резюме новыми навыками. Чего мне еще не хватает?
◾️Хочу освоить новые инструменты для работы, что там про Postman и Swagger говорят?

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

Всегда возможны разные пути роста, шагов вперед, и решение как это делать за вами. Что бы вы не выбрали - это верный путь и он приведет к результату! Главное идти по нему, а не просто лежать в направлении! 🙂

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

У вас есть план с примерными датами по развитию в карьере? Ставьте ❤️ Думаете о нем? Ставим 🔥

🔔Заканчивается предзапись на практическую программу "Дизайн REST API".

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

📆Старт предобучения: 1 ноября.
🔗 Записаться на практику по проектированию REST API

Уже нет… 😅

📌 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 у вас в компании? 🤔
Да - 👍 Нужен и задумываетесь о нём - ❤️