Согласно последним опросам, более 80% приложений в мире используют REST API, что делает его неотъемлемой частью любого крупного IT-проекта. Поэтому умение проектировать REST API становится востребованным навыком для системных аналитиков.

Если вы хотите освоить проектирование REST API, инструмент Swagger, используемый для создания интерактивной документации, и получить реальный опыт работы над проектом, то этот онлайн-практикум для вас!

📚 Про REST API за 2 часа: с нуля до Swagger-документации
📅 24 ЯНВАРЯ, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

План:
1. Самая важная теория по REST API и квиз для её закрепления.
2. Проектирование методов REST API с нуля.
3. Создание Swagger-документации для спроектированных методов.
4. Шаблон постановки задачи на разработку REST API-метода.

Подготовка к практикуму:
1. Зарегистрироваться в Swagger. Инструкция доступна по ссылке.
2. Прочитать базовую теорию по REST API в канале и следить за текущими публикациями.
3. В процессе онлайн-практикума работать с компьютера и быть активными в чате.


Хотите начать реальную работу с REST API?
Регистрируйтесь и подключайтесь к эфиру 24 января! 🚀🤗💪

До встречи встречи онлайн!

Привет!

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

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

Этот разбор примера поможет понять, какой результат ожидать в результате проектирования, и что из себя представляет контракт REST API 😎

🚀 Пример постановки задачи на REST API 🚀

---------------
🔸 Изменение продукта - PATCH /products/{productId}
---------------

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

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

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

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

Метод изменяет только те данные о продукте, которые переданы на вход.

Метод доступен только для авторизованных пользователей.

К изменению доступны параметры:
- название,
- описание,
- штрихкод,
- размер одной порции,
- количество ккал на 100 грамм,
- белги (г) на 100 грамм,
- жиры (г) на 100 грамм,
- углеводы (г) на 100 грамм.

Ограничения:
- Пользователь может менять только те продукты, которые он добавил в справочник сам, но не может менять продукты, которые создали другие пользователи приложения.
- Администратор может менять все записи в справочнике.
- При сохранении изменений проверять совпадения по названию и штрихкоду. Искать в базе похожие продукты и предлагать объединить их в один, если создается дубликат.
- Если продукт уже был добавлен к кому-то в употребленное меню за день, то изменения не должны повлиять на старые записи, которые есть у других пользователей. Для этого необходимо вести версионирование информации о продукте и при изменении увеличивать версию продукта на 1.
- Если при редактировании был удален один из обязательных параметров, то вернуть ошибку сохранения. Данные не обновлять.

Клиенты:
- Мобильное приложение G-Food - экран изменения информации о продукте.
- Приложение администратора - экран управления справочником продуктов - редактирование (ссылка).

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

🔸 Пример запроса:
PATCH https://g-food.com/api/public/1.0/products/{productId}
- query-параметры: нет
- headers:
-- content-type: application/json
- authorization: token пользователя.

Рост и результаты не даются мне легко!

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

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

Не подумайте, что обесцениваю учёбу в университете: было действительно продуктивно, так как я из тех, кто делал все ДЗ и учился на 5. А за программирование, проектирование БД и UML хочу сказать отдельное спасибо! 😅

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

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

Старт GetAnalyst ассоциируется с 10-14 часов работы в сутки, вдохновением и упорным трудом. У меня появилась цель: я не хотела от нее отказываться или откладывать, и шла к ней! Настолько быстро, насколько возможно.

До сих пор вспоминаю, как была в путешествиях, но выходила из отеля 2 раза в день: на час до спортзала, и на час погулять. А в выходные можно было работать только 4-6 часов, чтобы всё успевать. Тогда удавалось посмотреть всё что возможно за пару дней, или просто выдохнуть.

Сейчас, в январе 2024 года, я открываю телеграм-канал GetAnalyst и вижу результаты. Вас больше 5,5 тысяч! 🔥 Это небольшой футбольный стадион 😅

Вы меня читаете, приходите на вебинары, учитесь, и даёте приятную обратную связь! Это стоит всех усилий 🙌

Зачем я про это говорю? Затем, чтобы показать, как бывает.

Чтобы вырасти, требуется огромное количество сил, энергии, переживаний.
Каждый раз как из гусеницы в бабочку.
Это не бывает незаметным☝️
Без этого нет перемен, роста, новых идей и возможностей.

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

Мне хочется вас призвать:
Не стесняйтесь своих трудностей! Не думайте, что если сложно или вас кто-то не понимает, то значит нужно бросать!

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

Поддерживаю каждого, кто сейчас на стадии таких изменений 🫂 Потому что у меня опять идёт очередной рывок вперёд, и надеюсь, что уже очень скоро будет чем с вами поделиться 💫

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

А вас также хвалят на работе?😄

Завидуете коллегам, которые неуклонно развиваются в профессии? 🤔

Только честно!
Вслух можно не признаваться 😄

Порой кажется, что где-то тебя обошли вниманием, где-то не поднажал сам и «забуксовал» на одном месте.

Но я считаю, что зависть — это классное чувство. Она не должна закапывать и лишать мотивации ☝️ Это те самые маячки, которые подсвечивают нам: «хочу также»!

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

Напоминаю:
⚡️ 21 января заканчивается предзапись
🎯 Дизайн REST API - 2 месяца практики,
✅ где мы будем работать над одним проектом,
✅ чтобы с нуля описать требования к разработке.

Для кого-то из вас этот тот самый навык, который поднимет выше и придаст уверенности в своих знаниях 🙌

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

А главное - на собеседованиях по вопросам REST API вы сможете отвечать приводя реальные примеры, и покажете свои проекты из портфолио, которые мы создадим!

📌JSON - формат сообщений, используемый в REST API

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

JSON, что расшифровывается как "JavaScript Object Notation", является легковесным форматом данных, который легко читается и пишется как человеком, так и системами. Он основан на синтаксисе объекта языка программирования JavaScript, но существует независимо от языка.

Пример данных в формате JSON - объект "Пользователь":
{
"id": 1,
"name": "Степан",
"email": "stepan@email.com",
"isStudent": false,
"hobbies": ["футбол", "путешествия"]
}

В этом примере:

🔹Объект {} человека или пользователя, в зависимости от контекста системы. Всегда есть открывающаяся и закрывающаяся скобка.

🔹Пары ключ-значение: слева в кавычках ".." указывается название поля, а справа его значение. Что важно, название полей в JSON и в БД не обязательно совпадают.

🔹Показаны возможные типы данных: обратите внимание, что числа без кавычек, массивы (списки однотипных данных) в [], boolean - флаги да/нет (true/false) также без кавычек.

🔹camelCase - рекомендация по именованию полей.

JSON - стандарт в мире программирования и обработки данных. Он позволяет системам обмениваться структурированной в едином стиле информацией.


Для работы с JSON и самостоятельных экспериментов рекомендую: https://jsoneditoronline.com/

С помощью этого инструмента можно проверять себя, правильно ли вы строите объекты данных в этом формате.

✔ body (тело) запроса в JSON для метода PATCH ✔

Мы создаем пример постановки задачи для разработки метода изменения продукта PATCH.

Параметры, которые нужно изменить в результате обработки запроса, обычно не передаются в составе URL-запроса (query-параметры), а передаются в теле запроса (⚡️request body). Этот подход также распространяется на POST и PUT.


Метод PATCH позволяет полностью или частично менять объект данных. Это означает, что на вход методу PATCH мы можем передать:


❌ 1. Все параметры объекта.
Это актуально для PUT, но не для PATCH. Так лучше не делать.


✅ 2. Все параметры, доступные к изменению.
Можно и допустимо. Обычно этот вариант используют в примерах API-документации.


✅ 3. Только те параметры, которые планируем поменять.
Можно и допустимо, но этот вариант обычно показывают как дополнительный в примере API-документации, или не показывают вовсе.


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

Поэтому, для создания документации, мы будем описывать пример JSON, показывая все параметры, доступные к изменению.


Продолжение с примером JSON для PATCH /products/{productId} 👇

📌 JSON — пример запроса для шаблона документации 📌

PATCH /products/{productId} - изменение продукта для приложения подсчета калорий G-Food.

К изменению доступны параметры:
- название - "name" - строка,
- описание - "description" - строка,
- штрихкод - "barcode" - строка,
- размер одной порции (грамм) - "portionSizes” (допустимо несколько вариантов) - список с перечислением - название порции ("name") и кол-во грамм ("size"),
- количество ккал на 100 грамм - "kcal",
- белки (г) на 100 грамм - "proteins",
- жиры (г) на 100 грамм - "fats",
- углеводы (г) на 100 грамм - "carbs".

Далее мы дополнительно укажем типы данных для каждого параметра. На этапе описания маппинга.

JSON объекта будет выглядеть как:
{
"name": "Овсяные хлопья",
"description": "Хлопья из цельного овса, богаты клетчаткой и микроэлементами. \nОчень вкусные",
"barcode": "1234567890123",
"portionSizes": [
{
"name": "Маленькая порция",
"size": 30
},
{
"name": "Стандартная порция",
"size": 50
}
],
"kcal": 389,
"proteins": 13,
"fats": 6.9,
"carbs": 66.3
}


Разбирая строку "name": "Овсяные хлопья", уточняю:
🔸 "name" - ключ, название параметра в JSON. Может не совпадать с названием в БД и у тем более на UI.
🔸"Овсяные хлопья" - значение параметра. Берётся из БД, из таблицы с продуктами.



В качестве дополнительных примеров можно взять:
{
"name": "Овсяные хлопья",
"description": "Хлопья из цельного овса, богаты клетчаткой и микроэлементами. \nОчень вкусные",
}

или массив (список):

{
"portionSizes": [
{
"name": "Маленькая порция",
"size": 30
},
{
"name": "Стандартная порция",
"size": 50
}
]
}


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

Вставьте код в JSON Editor Online, чтобы проверить, что получилось 👍

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

Согласитесь, нетворкинг играет огромную роль в нашем успехе и самочувствии. Это как иметь в своем телефоне приложение "поддержка 24/7", только оно написано кодом дружбы и взаимопомощи. 😊

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

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

Иногда, чтобы продолжить движение вперед, нам просто нужно увидеть кого-то, кто уже там, на вершине своего горного пика, машущего нам и кричащего: "Давай, ты тоже можешь!”

И знаете, что самое крутое? Иногда для большого скачка вперед достаточно всего одного человека, одной улыбки или одного доброго слова. 🙌 Это как найти ластик, когда ты уже решил, что лист испорчен и назад дороги нет. Вдруг оказывается, что можно все исправить и начать с начала.

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

И помни, если когда-нибудь почувствуешь, что тебе нужен тот самый "ластик" или просто доброе слово - пиши нам! В чат, в личные сообщения. Если только зарядку от телефона не забыл дома 😄

Помни, мы твоя поддержка — это твоя суперсила! ❤️

С добром и теплом,
GetAnalyst.

Разработка требований к обработке ошибок в REST API - одна из самых важных и нужных тем к освоению.

Аналитики должны предусмотреть возможные сценарии работы системы: как успешные, так и возможные ошибки. Эти требования к поведению системы затем используются тестировщиками для проверки корректности работы Backend.

Если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄

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

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

При работе с ответами на запросы REST API проектируют две связанных между собой части:
1. Код HTTP-ответа: есть всегда и зависит от типа запроса или вида ошибки.
2. Тело ответа (⚡️response body): необязательное, может отсутствовать.

‼️HTTP-коды ответов в REST API и их назначение ‼️

Коды, которые должен знать наизусть каждый системный аналитик и разработчик.


🧑‍💻 HTTP-200: "ОК".
Успешное выполнение запроса. Используется преимущественно для GET, PUT, PATCH.

🧑‍💻 HTTP-201: "Создано".
Обычно возвращается для POST и PUT после успешного создания нового ресурса - записи данных в таблицу БД.

🧑‍💻 HTTP-400: "Плохой запрос".
Запрос не может быть обработан из-за неверного синтаксиса - формата запроса. Ошибка на стороне клиента. Например, в номере счета содержится буква или длина фамилии в запросе больше 128 символов, а ожидалось до 128.
Может сопровождаться красивым текстом сообщением, которое можно показать пользователю.

🧑‍💻 HTTP-401: "Неавторизован".
Запрос требует аутентификации пользователя, то есть выполняется приложением или пользователем без авторизации (логина+пароля или ключа доступа в виде токена).

🧑‍💻 HTTP-403: "Запрещено".
Сервер понял запрос, но он отказывается его выполнять. Как правило это связано с тем, что пользователь авторизован, но доступ запрещен - настройка прав доступа к API.

🧑‍💻 HTTP-404: "Не найдено".
Сервер не может найти запрашиваемый ресурс - данные в БД не найдены.

🧑‍💻 HTTP-500: "Внутренняя ошибка сервера".
Возникает, когда сервер столкнулся с ситуацией, которую он не знает как обработать. Ошибка в работе алгоритма.
Может сопровождаться красивым текстом сообщением, которое можно показать пользователю.

🧑‍💻 HTTP-503: "Сервис недоступен".
Сервер временно не может обрабатывать запросы по техническим причинам.


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

Напоминаю:
если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄


Сохраняйте важный пост, чтобы не потерять!

Проблемы у системных аналитиков при работе с REST API часто возникают из-за поверхностных знаний и отсутствия глубокого понимания его принципов.

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

😥 Основные трудности в работе с API:
- Необходимость вносить совместимые изменения.
- Отсутствие понимания структуры документации.
- Упущенные детали в требованиях, требующие постоянного уточнения.
- Непонимание как связан API с БД.
- Трудности в создании структуры JSON, удовлетворяющей будущим пользователям готового API.

💪 Для эффективной работы и уверенности на интервью требуется:
+ Глубокое понимание REST, его принципов и стандартов.
+ Наличие демонстрирующих навыки проектов - демо-портфолио API-документации.
+ Готовность к сложным вопросам по проектированию и оптимизации.
+ Понимание потенциальных проблем и способов их решения.
+ Умение обсуждать архитектуру систем.

Готовы начать глубокое погружение в тему REST API?

Подключайтесь сегодня онлайн в 19:00 МСК!