Завидуете коллегам, которые неуклонно развиваются в профессии? 🤔
Только честно!
Вслух можно не признаваться 😄
Порой кажется, что где-то тебя обошли вниманием, где-то не поднажал сам и «забуксовал» на одном месте.
Но я считаю, что зависть — это классное чувство. Она не должна закапывать и лишать мотивации ☝️ Это те самые маячки, которые подсвечивают нам: «хочу также»!
Да, и будем честными.
Наши коллеги, на которых мы смотрим, не сверхлюди.
Они обладают чуть большими навыками, которые приобрели за счёт новых знаний и опыта. Их стремление расти, четкий план и цели, позволяют им быть впереди. Но и вы тоже так можете! И даже лучше!
Напоминаю:
⚡️ 21 января заканчивается предзапись
🎯 Дизайн REST API - 2 месяца практики,
✅ где мы будем работать над одним проектом,
✅ чтобы с нуля описать требования к разработке.
Для кого-то из вас этот тот самый навык, который поднимет выше и придаст уверенности в своих знаниях 🙌
За 2 месяца мы полноценно разберемся во всех особенностях проектирования REST API, познакомимся с инструментами тестирования и документирования, разберемся как ставить задачи на разработчиков и аргументировать свои технические решения.
А главное - на собеседованиях по вопросам REST API вы сможете отвечать приводя реальные примеры, и покажете свои проекты из портфолио, которые мы создадим!
Только честно!
Вслух можно не признаваться 😄
Порой кажется, что где-то тебя обошли вниманием, где-то не поднажал сам и «забуксовал» на одном месте.
Но я считаю, что зависть — это классное чувство. Она не должна закапывать и лишать мотивации ☝️ Это те самые маячки, которые подсвечивают нам: «хочу также»!
Да, и будем честными.
Наши коллеги, на которых мы смотрим, не сверхлюди.
Они обладают чуть большими навыками, которые приобрели за счёт новых знаний и опыта. Их стремление расти, четкий план и цели, позволяют им быть впереди. Но и вы тоже так можете! И даже лучше!
Напоминаю:
⚡️ 21 января заканчивается предзапись
🎯 Дизайн REST API - 2 месяца практики,
✅ где мы будем работать над одним проектом,
✅ чтобы с нуля описать требования к разработке.
Для кого-то из вас этот тот самый навык, который поднимет выше и придаст уверенности в своих знаниях 🙌
За 2 месяца мы полноценно разберемся во всех особенностях проектирования REST API, познакомимся с инструментами тестирования и документирования, разберемся как ставить задачи на разработчиков и аргументировать свои технические решения.
А главное - на собеседованиях по вопросам REST API вы сможете отвечать приводя реальные примеры, и покажете свои проекты из портфолио, которые мы создадим!
⚡3❤2🤯1
📌JSON - формат сообщений, используемый в REST API
Одним из ключевых форматов, используемых для представления и передачи данных, является JSON. И его понимание нам нужно, прежде чем мы перейдем к следующему этапу разбора шаблона постановки задачи на REST API.
JSON, что расшифровывается как "JavaScript Object Notation", является легковесным форматом данных, который легко читается и пишется как человеком, так и системами. Он основан на синтаксисе объекта языка программирования JavaScript, но существует независимо от языка.
Пример данных в формате JSON - объект "Пользователь":
В этом примере:
🔹Объект {} человека или пользователя, в зависимости от контекста системы. Всегда есть открывающаяся и закрывающаяся скобка.
🔹Пары ключ-значение: слева в кавычках ".." указывается название поля, а справа его значение. Что важно, название полей в JSON и в БД не обязательно совпадают.
🔹Показаны возможные типы данных: обратите внимание, что числа без кавычек, массивы (списки однотипных данных) в [], boolean - флаги да/нет (true/false) также без кавычек.
🔹camelCase - рекомендация по именованию полей.
JSON - стандарт в мире программирования и обработки данных. Он позволяет системам обмениваться структурированной в едином стиле информацией.
Для работы с JSON и самостоятельных экспериментов рекомендую: https://jsoneditoronline.com/
С помощью этого инструмента можно проверять себя, правильно ли вы строите объекты данных в этом формате.
Одним из ключевых форматов, используемых для представления и передачи данных, является 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/
С помощью этого инструмента можно проверять себя, правильно ли вы строите объекты данных в этом формате.
👍17❤11🔥3
✔ 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} 👇
Мы создаем пример постановки задачи для разработки метода изменения продукта PATCH.
Параметры, которые нужно изменить в результате обработки запроса, обычно не передаются в составе URL-запроса (query-параметры), а передаются в теле запроса (⚡️request body). Этот подход также распространяется на POST и PUT.
Метод PATCH позволяет полностью или частично менять объект данных. Это означает, что на вход методу PATCH мы можем передать:
❌ 1. Все параметры объекта.
Это актуально для PUT, но не для PATCH. Так лучше не делать.
✅ 2. Все параметры, доступные к изменению.
Можно и допустимо. Обычно этот вариант используют в примерах API-документации.
✅ 3. Только те параметры, которые планируем поменять.
Можно и допустимо, но этот вариант обычно показывают как дополнительный в примере API-документации, или не показывают вовсе.
Аналитики и разработчики, которые будут делать интеграцию с вашим приложением, хотят получать из примера JSON в API-документации информацию обо всех доступных к изменению параметрах. Так удобнее и быстрее.
Поэтому, для создания документации, мы будем описывать пример JSON, показывая все параметры, доступные к изменению.
Продолжение с примером JSON для PATCH /products/{productId} 👇
👌10❤5👍1🔥1
📌 JSON — пример запроса для шаблона документации 📌
К изменению доступны параметры:
- название - "name" - строка,
- описание - "description" - строка,
- штрихкод - "barcode" - строка,
- размер одной порции (грамм) - "portionSizes” (допустимо несколько вариантов) - список с перечислением - название порции ("name") и кол-во грамм ("size"),
- количество ккал на 100 грамм - "kcal",
- белки (г) на 100 грамм - "proteins",
- жиры (г) на 100 грамм - "fats",
- углеводы (г) на 100 грамм - "carbs".
Далее мы дополнительно укажем типы данных для каждого параметра. На этапе описания маппинга.
JSON объекта будет выглядеть как:
Разбирая строку "name": "Овсяные хлопья", уточняю:
🔸 "name" - ключ, название параметра в JSON. Может не совпадать с названием в БД и у тем более на UI.
🔸"Овсяные хлопья" - значение параметра. Берётся из БД, из таблицы с продуктами.
В качестве дополнительных примеров можно взять:
или массив (список):
Помните, развернутый и максимально описанный пример поможет тем, кто использует ваш API для интеграции, лучше и быстрее понять как у вас устроено управление данными об объекте.
Вставьте код в JSON Editor Online, чтобы проверить, что получилось 👍
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, чтобы проверить, что получилось 👍
❤8👍3🔥1
Я все чаще задумываюсь о том, насколько важно окружать себя правильными людьми.
Согласитесь, нетворкинг играет огромную роль в нашем успехе и самочувствии. Это как иметь в своем телефоне приложение "поддержка 24/7", только оно написано кодом дружбы и взаимопомощи. 😊
Каждый раз, когда мы встречаем кого-то, кто разделяет наши устремления или уже достиг того, к чему мы стремимся, это не просто пополнение списка контактов. Это шанс учиться, делиться и расти.
💪 Настоящее сообщество — это не просто группа людей, это сила, которая заставляет нас чувствовать, что мы можем свернуть горы.
Иногда, чтобы продолжить движение вперед, нам просто нужно увидеть кого-то, кто уже там, на вершине своего горного пика, машущего нам и кричащего: "Давай, ты тоже можешь!”
И знаете, что самое крутое? Иногда для большого скачка вперед достаточно всего одного человека, одной улыбки или одного доброго слова. 🙌 Это как найти ластик, когда ты уже решил, что лист испорчен и назад дороги нет. Вдруг оказывается, что можно все исправить и начать с начала.
Давайте ценить эту связь, эти маленькие и большие встречи, потому что в конце концов, когда мы вместе, возможно все.
И помни, если когда-нибудь почувствуешь, что тебе нужен тот самый "ластик" или просто доброе слово - пиши нам! В чат, в личные сообщения. Если только зарядку от телефона не забыл дома 😄
Помни, мы твоя поддержка — это твоя суперсила! ❤️
С добром и теплом,
GetAnalyst.
Согласитесь, нетворкинг играет огромную роль в нашем успехе и самочувствии. Это как иметь в своем телефоне приложение "поддержка 24/7", только оно написано кодом дружбы и взаимопомощи. 😊
Каждый раз, когда мы встречаем кого-то, кто разделяет наши устремления или уже достиг того, к чему мы стремимся, это не просто пополнение списка контактов. Это шанс учиться, делиться и расти.
💪 Настоящее сообщество — это не просто группа людей, это сила, которая заставляет нас чувствовать, что мы можем свернуть горы.
Иногда, чтобы продолжить движение вперед, нам просто нужно увидеть кого-то, кто уже там, на вершине своего горного пика, машущего нам и кричащего: "Давай, ты тоже можешь!”
И знаете, что самое крутое? Иногда для большого скачка вперед достаточно всего одного человека, одной улыбки или одного доброго слова. 🙌 Это как найти ластик, когда ты уже решил, что лист испорчен и назад дороги нет. Вдруг оказывается, что можно все исправить и начать с начала.
Давайте ценить эту связь, эти маленькие и большие встречи, потому что в конце концов, когда мы вместе, возможно все.
И помни, если когда-нибудь почувствуешь, что тебе нужен тот самый "ластик" или просто доброе слово - пиши нам! В чат, в личные сообщения. Если только зарядку от телефона не забыл дома 😄
Помни, мы твоя поддержка — это твоя суперсила! ❤️
С добром и теплом,
GetAnalyst.
❤🔥35🥰4👍3🤔1
Разработка требований к обработке ошибок в REST API - одна из самых важных и нужных тем к освоению.
Аналитики должны предусмотреть возможные сценарии работы системы: как успешные, так и возможные ошибки. Эти требования к поведению системы затем используются тестировщиками для проверки корректности работы Backend.
Если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄
Тестировщики, после окончания разработки, проверяют ошибки API зафиксированные требованиях, а также придумывают нестандартные ситуации, чтобы убедиться в корректности его работы в самых разных ситуациях.
Важно, чтобы список обрабатываемых ошибок был доступен в API-документации для его клиентов: мобильных и веб-приложений, других систем. Когда другие клиенты знают о поддержанных в API ошибках, то со своей стороны могут подготовиться к их красивой обработке: отображение корректных сообщений и визуальных элементов конечным пользователям.
При работе с ответами на запросы REST API проектируют две связанных между собой части:
1. Код HTTP-ответа: есть всегда и зависит от типа запроса или вида ошибки.
2. Тело ответа (⚡️response body): необязательное, может отсутствовать.
Аналитики должны предусмотреть возможные сценарии работы системы: как успешные, так и возможные ошибки. Эти требования к поведению системы затем используются тестировщиками для проверки корректности работы Backend.
Если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄
Тестировщики, после окончания разработки, проверяют ошибки API зафиксированные требованиях, а также придумывают нестандартные ситуации, чтобы убедиться в корректности его работы в самых разных ситуациях.
Важно, чтобы список обрабатываемых ошибок был доступен в API-документации для его клиентов: мобильных и веб-приложений, других систем. Когда другие клиенты знают о поддержанных в API ошибках, то со своей стороны могут подготовиться к их красивой обработке: отображение корректных сообщений и визуальных элементов конечным пользователям.
При работе с ответами на запросы REST API проектируют две связанных между собой части:
1. Код HTTP-ответа: есть всегда и зависит от типа запроса или вида ошибки.
2. Тело ответа (⚡️response body): необязательное, может отсутствовать.
👍14🔥3❤2💯1
‼️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 и анализе поведения системы.
Напоминаю:
если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄
Сохраняйте важный пост, чтобы не потерять!
Коды, которые должен знать наизусть каждый системный аналитик и разработчик.
🧑💻 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 и анализе поведения системы.
Напоминаю:
если обработку ошибок не заложить в требования, то сама она автоматически не появится. Увы 😄
Сохраняйте важный пост, чтобы не потерять!
👌11👍10❤🔥7❤2
📚 Про REST API за 2 часа: с нуля до Swagger-документации
📅 24 ЯНВАРЯ, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Как подготовиться к участию в проекте по REST API завтра, чтобы получить результат? 👀
1️⃣
Минимум: Посмотреть пост Всё о REST API в одной картинке.
Максимум: Перечитать всё, что было связано с проектированием API, начиная с определения API, или с определения REST API.
2️⃣
Минимум: Зарегистрироваться в Swagger и проверить, что он работает (для кого-то доступен только с VPN).
Максимум: Зарегистрироваться в Swagger и создать тестовый проект.
Инструкция Swagger тут.
3️⃣
Подключиться с компьютера и быть готовыми писать в чате ответы на вопросы и присылать результаты проектирования на проверку, фиксировать полезные и вдохновляющие заметки.
До встречи завтра, в прямом эфире! ❤️
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11
Проблемы у системных аналитиков при работе с REST API часто возникают из-за поверхностных знаний и отсутствия глубокого понимания его принципов.
Подходы, основанные на интуиции и просмотре чужой документации, неизбежно приводят к ошибкам, заметным при реальной работе и при прохождении технических собеседований на позицию middle и выше системного аналитика.
😥 Основные трудности в работе с API:
- Необходимость вносить совместимые изменения.
- Отсутствие понимания структуры документации.
- Упущенные детали в требованиях, требующие постоянного уточнения.
- Непонимание как связан API с БД.
- Трудности в создании структуры JSON, удовлетворяющей будущим пользователям готового API.
💪 Для эффективной работы и уверенности на интервью требуется:
+ Глубокое понимание REST, его принципов и стандартов.
+ Наличие демонстрирующих навыки проектов - демо-портфолио API-документации.
+ Готовность к сложным вопросам по проектированию и оптимизации.
+ Понимание потенциальных проблем и способов их решения.
+ Умение обсуждать архитектуру систем.
Готовы начать глубокое погружение в тему REST API?
Подключайтесь сегодня онлайн в 19:00 МСК!
Подходы, основанные на интуиции и просмотре чужой документации, неизбежно приводят к ошибкам, заметным при реальной работе и при прохождении технических собеседований на позицию middle и выше системного аналитика.
😥 Основные трудности в работе с API:
- Необходимость вносить совместимые изменения.
- Отсутствие понимания структуры документации.
- Упущенные детали в требованиях, требующие постоянного уточнения.
- Непонимание как связан API с БД.
- Трудности в создании структуры JSON, удовлетворяющей будущим пользователям готового API.
💪 Для эффективной работы и уверенности на интервью требуется:
+ Глубокое понимание REST, его принципов и стандартов.
+ Наличие демонстрирующих навыки проектов - демо-портфолио API-документации.
+ Готовность к сложным вопросам по проектированию и оптимизации.
+ Понимание потенциальных проблем и способов их решения.
+ Умение обсуждать архитектуру систем.
Готовы начать глубокое погружение в тему REST API?
Подключайтесь сегодня онлайн в 19:00 МСК!
👌13👍8
❗️До начала 15 минут❗️
📹 Про REST API за 2 часа: с нуля до Swagger-документации
Переходите по ссылке: https://pruffme.com/webinar/?id=cfbaba2b3142b38994e60652dbe9760d и начинаем!
Please open Telegram to view this post
VIEW IN TELEGRAM
Pruffme
Про REST API за 2 часа: с нуля до Swagger-документации
⚡4🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
🔥27🥰26❤🔥8👏7
Доброго утра и дня! Что вчера было? 🔥 3.5 часа практики!
Сначала я дала вводные по проекту и рассказала базовую теорию по REST API. а потом!!! 9 практических заданий, которые вы выполнили, и много ваших крутых вопросов!
Разобрали:
👉 Что из себя представляет REST API и структуру метода.
👉 По каждому пункту из сруктуры метода разрабатывали и проходили квизы!
👉 Разбирались когда POST, когда PUT, и в чем разница.
👉 SOAP vs REST.
👉 Связь БД, UI и API.
👉 Посмотрели как делать JSON-ы в http://jsoneditoronline.com.
👉 Работали со Swagger-документацией и наблюдали с какими первичными проблемами можно встретиться.
👉 И много других деталей!
Дополнительные инструменты для работы с JSON:
👉 notepad++
👉 https://www.jetbrains.com/idea/
На выходе с практикума у ребят остались:
🔑 Инструкция по наполнению корпоративного гайда по дизайну REST API.
🔑 В течение этой недели пришлю вам исходники Swagger-документации, над которой работали!
🔑 Знания по REST API: как создавать методы с нуля.
🔑 Опыт!
В конце я рассказала о старте практической программы REST API с 31 января, и ближайшую неделю будет открыта запись в нашу команду системных аналитиков!
Вау? Вау! Вы лучшие! Спасибо за активность и вопросы! 🔥❤️
P.S. Регистрация на повтор будет открыта завтра, т.к. 3.5 часа практики опять. Если я разбираю тему, то копаю и делюсь с вами всеми важными деталями. Это важно 🙌
P.S.S. Мы побили рекорд по количеству участников. Спасибо за такой старт 2024! ❤️
Сначала я дала вводные по проекту и рассказала базовую теорию по REST API. а потом!!! 9 практических заданий, которые вы выполнили, и много ваших крутых вопросов!
Разобрали:
👉 Что из себя представляет REST API и структуру метода.
👉 По каждому пункту из сруктуры метода разрабатывали и проходили квизы!
👉 Разбирались когда POST, когда PUT, и в чем разница.
👉 SOAP vs REST.
👉 Связь БД, UI и API.
👉 Посмотрели как делать JSON-ы в http://jsoneditoronline.com.
👉 Работали со Swagger-документацией и наблюдали с какими первичными проблемами можно встретиться.
👉 И много других деталей!
Дополнительные инструменты для работы с JSON:
👉 notepad++
👉 https://www.jetbrains.com/idea/
На выходе с практикума у ребят остались:
🔑 Инструкция по наполнению корпоративного гайда по дизайну REST API.
🔑 В течение этой недели пришлю вам исходники Swagger-документации, над которой работали!
🔑 Знания по REST API: как создавать методы с нуля.
🔑 Опыт!
В конце я рассказала о старте практической программы REST API с 31 января, и ближайшую неделю будет открыта запись в нашу команду системных аналитиков!
Вау? Вау! Вы лучшие! Спасибо за активность и вопросы! 🔥❤️
P.S. Регистрация на повтор будет открыта завтра, т.к. 3.5 часа практики опять. Если я разбираю тему, то копаю и делюсь с вами всеми важными деталями. Это важно 🙌
P.S.S. Мы побили рекорд по количеству участников. Спасибо за такой старт 2024! ❤️
🔥41❤7🥰3👍2👎1
В Postman есть большая коллекция открытой API-документации, с которой можно самостоятельно пробовать разобраться с REST API и особенностями работы с этим ключевым инструментом для аналитиков 👀
Вот несколько полезных ссылок:
🔗 Коллекция открытых API
ChatGPT 3 - API
🔗 Open AI GPT3
🔗 Документация
Что с этим делать?
✔️ Смотреть как настраивать запросы postman, в частности аналитикам часто интересны headers, authorization
✔️ Пробовать тестировать открытый API
✔️ Изучать подходы к проектированию API от разных компаний, смотреть отличия
✔️ Смотреть подходы разных компаний к документированию API в Postman
Пересылайте себе в личные сообщения, чтобы сохранить ссылки и попробовать возможности Postman на максимум! 🔥
Вот несколько полезных ссылок:
🔗 Коллекция открытых API
ChatGPT 3 - API
🔗 Open AI GPT3
🔗 Документация
Что с этим делать?
✔️ Смотреть как настраивать запросы postman, в частности аналитикам часто интересны headers, authorization
✔️ Изучать подходы к проектированию API от разных компаний, смотреть отличия
Пересылайте себе в личные сообщения, чтобы сохранить ссылки и попробовать возможности Postman на максимум! 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16⚡7❤4👍1
📚 Про REST API за
📅 26, 25 и 27 ЯНВАРЯ
Очень структурированно и подробно разобрали всю структуру методов REST API! Это огромный объем проделанной мной работы по подготовке и результат....
Коллеги поделились впечатлениями после вебинара 🙂
Егор
Очень понравился вебинар! Особенно хотелось бы отметить практико-ориентированность.
Светлана
Екатерина, очень живо и полезно! Хожу к Вам на все открытые вебинары, благодаря Вашему заряду, решилась из саппорта перейти в аналитику. Очень хочу учиться у Вас.
Евгения
Спасибо большое за вебинар! Дорогого стоит для тех, кто приступает к rest api. Очень доступно и понятно, последовательно
Ирина
Крутейший вебинар, большое спасибо! Огромный кусок информации, которого мне не хватило на пройденных мной курсах. Великолепная подача материала, приятно смотреть и слушать, очень понравилось. Обязательно приду еще на вебинары, даже курс захотелось купить)
Самое время узнать почему такая обратная связь! 😉
📌 ТОЛЬКО 3 ДНЯ!
Это важная тема! Запланируйте время, чтобы не пропустить 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👌5❤3❤🔥2
Часовые пояса - это челлендж. Для вас, и для меня. Почти с каждым у нас разница минимум 10 часов, а то и больше. Поэтому эфиры начинаются в 19 Мск (8 утра по моему времени), чтобы я была с вами с зарядом энегнии, а не угасающим огоньком.
Онлайн-практикумы - это не просто прийти, рассказать теорию и уйти. Это также про то, чтобы предать вам реальный опыт и вдохновить вас. Вы можете больше! Всегда есть куда расти, потолка нет!
Я искренне благодарна каждому, кто остаётся до самого конца онлайн, несмотря на поздний час. Ваше участие и вовлеченность - это то, ради чего стоит все это делать. Именно поэтому мы решили подготовить повтор нашего вебинара, чтобы каждый мог присоединиться, несмотря на часовые пояса.
Во время нашего последнего вебинара я обещала вам специальное предложение по программе Дизайн REST API. И вот оно:
🎁 Промокод: REST240124
⏲ Активен только 27 января с 0:00 до 23:59 Мск
Этот промокод даст вам скидку на обучение, соответствующую специальному предложению, о котором мы говорили онлайн в конце практики. Код указывается на странице оплаты. Это маленький жест благодарности за ваше участие и стремление к новым достижениям!
Спасибо, что вы часть GetAnalyst! 🙌
P.S. Регистрация на повтор вебинара про REST API и Swagger☝️
Онлайн-практикумы - это не просто прийти, рассказать теорию и уйти. Это также про то, чтобы предать вам реальный опыт и вдохновить вас. Вы можете больше! Всегда есть куда расти, потолка нет!
Я искренне благодарна каждому, кто остаётся до самого конца онлайн, несмотря на поздний час. Ваше участие и вовлеченность - это то, ради чего стоит все это делать. Именно поэтому мы решили подготовить повтор нашего вебинара, чтобы каждый мог присоединиться, несмотря на часовые пояса.
Во время нашего последнего вебинара я обещала вам специальное предложение по программе Дизайн REST API. И вот оно:
🎁 Промокод: REST240124
⏲ Активен только 27 января с 0:00 до 23:59 Мск
Этот промокод даст вам скидку на обучение, соответствующую специальному предложению, о котором мы говорили онлайн в конце практики. Код указывается на странице оплаты. Это маленький жест благодарности за ваше участие и стремление к новым достижениям!
Спасибо, что вы часть GetAnalyst! 🙌
P.S. Регистрация на повтор вебинара про REST API и Swagger☝️
❤15🔥7👍4
🤖 ChatGPT для проектирования REST API 🤖
Год назад появился искусственный интеллект — ChatGPT. Созданный на основе знаний всего интернета, он становится помощником и для системных аналитиков, в том числе в проектировании REST API.
Чтобы работать с ним и иметь качественные результаты, важно уметь правильно задать контекст и знать последовательность команд для работы над задачей. Тогда он сможет выполнить за вас часть работы.
Пример команды:
Следует помнить, что, несмотря на его обширные знания, ChatGPT не является всезнающим. Он может допускать ошибки, и важно уметь отличать корректную информацию от некорректной, которую он выдает в результате выполнения запросов.
Кроме того, ChatGPT не знает уникальной информации о вашей компании или конкретных проектах. Так что, пока он помогает с общими задачами, все тонкости проектирования API вам придется учитывать самостоятельно, основываясь на вашем опыте и знаниях. Иначе есть риск получить «кривые» решения.
В ходе работы я собираю и сохраняю различные команды для работы с ChatGPT. Это позволяет мне максимально эффективно использовать его возможности.
Однако ключевым моментом является способность взаимодействовать с ним как с дополнительным инструментом в работе системного аналитика, и корректировать его ответы в соответствии с реальным миром и вашими задачами.
Год назад появился искусственный интеллект — ChatGPT. Созданный на основе знаний всего интернета, он становится помощником и для системных аналитиков, в том числе в проектировании REST API.
Чтобы работать с ним и иметь качественные результаты, важно уметь правильно задать контекст и знать последовательность команд для работы над задачей. Тогда он сможет выполнить за вас часть работы.
Пример команды:
Работай как системный аналитик.
Проект - [Название проекта].
[Описание ключевых данных о проекте, важных для решения задачи].
Спроектируй метод REST API: [Название метода].
1. Сделай описание метода - что это и для чего.
2. Опиши логику его работы - алгоритм.
3. Покажи пример запроса и ответа. Ответы нужны как успешный, так и обработка ошибок.Следует помнить, что, несмотря на его обширные знания, ChatGPT не является всезнающим. Он может допускать ошибки, и важно уметь отличать корректную информацию от некорректной, которую он выдает в результате выполнения запросов.
Кроме того, ChatGPT не знает уникальной информации о вашей компании или конкретных проектах. Так что, пока он помогает с общими задачами, все тонкости проектирования API вам придется учитывать самостоятельно, основываясь на вашем опыте и знаниях. Иначе есть риск получить «кривые» решения.
В ходе работы я собираю и сохраняю различные команды для работы с ChatGPT. Это позволяет мне максимально эффективно использовать его возможности.
Однако ключевым моментом является способность взаимодействовать с ним как с дополнительным инструментом в работе системного аналитика, и корректировать его ответы в соответствии с реальным миром и вашими задачами.
❤20🤔5👍1👎1
🛡️ Безопасность в REST API: 3 способа авторизации 🛡️
Безопасность обмена данными уже давно играет первостепенную роль в проектировании приложений. В случае с проектированием REST API от выбора способа авторизации зависит конфиденциальность данных.
Есть три основных способа авторизации:
⚪️ Basic Authentication (логин + пароль):
Простейший метод, при котором логин и пароль отправляются в заголовке запроса в формате Base64. Хоть это и базовый подход, без дополнительного SSL/TLS он является уязвимым.
Пример: МойСклад
⚪️ API-ключи (токены):
Эти уникальные идентификаторы позволяют приложениям получать доступ к API. Они обычно отправляются в заголовке запроса. Главный минус? Если ключ утек, его могут использовать злоумышленники. Хотя от этого можно защититься.
Пример: МойСклад (альтернативный способ к Basic)
⚪️ OAuth:
Самый современный и безопасный метод. OAuth позволяет пользователям давать приложениям ограниченный доступ к своим ресурсам без раскрытия своих учетных данных. Он сложен в понимании, если просто читать про него теорию. Но попробовав применить его на практике, понимание приходит!
Пример: vk
В каждом из них нужно хорошо разбираться, чтобы правильно подходить к работе с задачами на интеграции и на проектирование API.
🔐 Помните, выбор метода авторизации должен соответствовать требованиям безопасности вашего приложения. В ваших руках безопасность пользовательских данных! Как системные аналитики вы влияете на решение вместе со специалистами по безопасности, архитекторами и backend-разработчиками.
Безопасность обмена данными уже давно играет первостепенную роль в проектировании приложений. В случае с проектированием REST API от выбора способа авторизации зависит конфиденциальность данных.
Есть три основных способа авторизации:
⚪️ Basic Authentication (логин + пароль):
Простейший метод, при котором логин и пароль отправляются в заголовке запроса в формате Base64. Хоть это и базовый подход, без дополнительного SSL/TLS он является уязвимым.
Пример: МойСклад
⚪️ API-ключи (токены):
Эти уникальные идентификаторы позволяют приложениям получать доступ к API. Они обычно отправляются в заголовке запроса. Главный минус? Если ключ утек, его могут использовать злоумышленники. Хотя от этого можно защититься.
Пример: МойСклад (альтернативный способ к Basic)
⚪️ OAuth:
Самый современный и безопасный метод. OAuth позволяет пользователям давать приложениям ограниченный доступ к своим ресурсам без раскрытия своих учетных данных. Он сложен в понимании, если просто читать про него теорию. Но попробовав применить его на практике, понимание приходит!
Пример: vk
В каждом из них нужно хорошо разбираться, чтобы правильно подходить к работе с задачами на интеграции и на проектирование API.
🔐 Помните, выбор метода авторизации должен соответствовать требованиям безопасности вашего приложения. В ваших руках безопасность пользовательских данных! Как системные аналитики вы влияете на решение вместе со специалистами по безопасности, архитекторами и backend-разработчиками.
👍16❤7👏1