Доброго утра и дня! Что вчера было? 🔥 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": "Описание задачи"
}

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

🧑‍💻Карьера системного аналитика: преподнесение навыка REST API в резюме и подборка вопросов с собеседований 🧑‍💻

Один из must have навыков для современного аналитика стало умение проектировать API. Давайте разберемся, как этот навык лучше всего представить в резюме и на что стоит быть готовым на собеседовании.

📌 Как преподносить навык REST API в резюме:

▫️Конкретизируйте ваш опыт: Не просто укажите "Знание REST API", но и опишите, как вы его использовали — например, "Разработка и документирование REST API для интеграции между CRM и ERP системами".

▫️Проекты: Если у вас были крупные проекты, связанные с интеграциями и API, укажите их. Это даст работодателю понять глубину вашего опыта.

▫️Инструменты: Упомяните, с какими инструментами (например, Postman, Swagger) вы работали в контексте REST API.


📌 Подборка вопросов с собеседований на системного аналитика по REST API:

▫️Расскажите о вашем опыте работы с RESTful API. С какими проблемами сталкивались и как решали? Приведите примеры.

▫️ Какие методы HTTP вы знаете?

▫️ В чем разница между POST и PUT?

▫️ Опишите стандартный процесс проектирования REST API на вашем последнем месте работы.

▫️ Как вы обеспечиваете безопасность API? Знакомы ли вы с OAuth?

▫️ Что такое идемпотентность и какие HTTP методы являются идемпотентными?

▫️ Как вы документируете API? Использовали ли вы инструменты автоматической генерации документации? Какие?

▫️ Как реализовать обработку большого объема данных через REST API?

▫️Как проектировать асинхронные запросы?

▫️ Можно ли передавать файлы через REST API? Как?

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

Сохраняйте подборку вопросов в шпаргалки, смотрите одно из наших видео про асинхронные запросы (звук плохой - суть важная).

Разбор ответов и опыт по этим вопросам я даю на практической программе - Дизайн REST API. Последний поток в этом году стартует уже 1 ноября!

Сохраняйте пост! Успехов!

🛡️ Безопасность в REST API: Три ключевых метода авторизации


Безопасность обмена данными уже давно играет первостепенную роль в проектировании приложений. В случае с проектированием REST API от выбора способа авторизации зависит конфиденциальность данных.

Есть три основных способа авторизации, которые мы разбираем на программе REST API:

⚪️ Basic Authentication (логин + пароль):
Простейший метод, при котором логин и пароль отправляются в заголовке запроса в формате Base64. Хоть это и базовый подход, без дополнительного SSL/TLS он является уязвимым.
Пример: МойСклад

⚪️ API-ключи (токены):
Эти уникальные идентификаторы позволяют приложениям получать доступ к API. Они обычно отправляются в заголовке запроса. Главный минус? Если ключ утек, его могут использовать злоумышленники. Хотя от этого можно защититься.
Пример: МойСклад (альтернативный способ к Basic)

⚪️ OAuth:
Самый современный и безопасный метод. OAuth позволяет пользователям давать приложениям ограниченный доступ к своим ресурсам без раскрытия своих учетных данных. Он сложен в понимании, если просто читать про него теорию. Но попробовав применить его на практике, понимание приходит!
Пример: vk


🔐 Помните, выбор метода авторизации должен соответствовать требованиям безопасности вашего приложения. В ваших руках безопасность пользовательских данных! Как системные аналитики вы влияете на решение вместе со специалистами по безопасности, архитекторами и backend-разработчиками.

Вам, возможно, уже приходилось сталкиваться с тем, как приложения запрашивают доступ к вашим данным в других сервисах.


Примеры:

🟡 При входе в приложение для редактирования фотографий, Вам предлагают воспользоваться учетной записью ВК/Яндекс/Mail.ru/Google, чтобы вы могли использовать эту учетную запись для входа, а также иметь легкий доступ к связанным с этой учетной записью фотографиям.

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

🟡 Приложения для фитнеса: Когда вы хотите синхронизировать данные о своей физической активности между различными фитнес-приложениями или устройствами, одно из приложений может запросить доступ к данным другого.

🟡 Приложения для учета расходов: Если вы используете приложение для учета личных финансов и хотите, чтобы оно автоматически импортировало информацию о ваших транзакциях из вашего банка, приложение будет запрашивать доступ к вашему банковскому аккаунту.


Но как это все работает с точки зрения безопасности? Ответ — OAuth 2.0.

🔍 Что такое OAuth 2.0?
Это стандартная процедура авторизации, которая позволяет пользователям безопасно делиться своими данными между различными приложениями.

Основное преимущество OAuth 2.0 в том, что пользователи не делятся своими учетными данными прямо с приложением, которому они предоставляют доступ.


🔄 Как это работает?
Представьте, что у вас есть приложение для фитнеса, и вы хотите передать его данные в приложение для планирования питания.

Вместо того чтобы вводить свой логин и пароль от фитнес-приложения в приложение планирования, вы просто даете разрешение на передачу определенных данных, используя OAuth 2.0.

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


🎭 Ключевые роли в OAuth 2.0 на примере с приложением по фитнесу

🔹 Владелец ресурса: это пользователь, который предоставляет доступ к своим данным.
▫️ Пользователь приложения фитнеса, который регистрируется в приложении по питанию.

🔹Клиент: приложение, запрашивающее доступ к данным.
▫️ Приложение питания.

🔹Сервер авторизации: выдает токены доступа клиенту после успешной авторизации.
▫️ Это на стороне приложения фитнеса.

Продолжим завтра 👇

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

🔐 Токены доступа и обновления в OAuth:
Токен доступа (access_token) — это ваш "ключ" к данным. Он имеет ограниченный срок действия и может быть обновлен с помощью токена обновления (refresh_token), который обычно действует дольше.


✅ Преимущества OAuth 2.0:
Простой и понятный процесс авторизации.
Возможность выбора между различными типами токенов.
Повышенная безопасность и контроль пользователей над их данными.


🛡 Лучшие практики при работе с OAuth 2.0:
- Используйте токены доступа с коротким сроком действия.
- Ограничивайте область действия токена.
- Защитите свое приложение от распространенных атак.
- Обеспечьте безопасное хранение и передачу токенов.
- Позволяйте пользователям отзывать доступ к их данным.
- Предоставляйте понятную документацию.
- Следуя этим принципам и понимая основы OAuth 2.0, вы сможете обеспечивать высокий уровень безопасности при интеграции с различными API и улучшать UX в ваших системах.