💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

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


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#RestApiGA

✨ Дизайн REST API с 6 мая - открыта запись в новый поток практической программы ✨

Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:

+ Знание REST API / JSON
+ Опыт проектирования и документирования API
+ Понимание принципов работы мобильных приложений
+ Знание OpenAPI / Swagger для создания REST API документации
+ Навык тестирования API Backend (Postman)

Все эти навыки, в разных формулировках, ожидают от Middle и Senior Системных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.


Мы осваиваем их в рамках одного большого проекта, на практической программе:

💻 Дизайн REST API
🗓 Старт 6 мая 2025
✅ Первая онлайн-встреча: 13 мая

🔗 Узнать подробности и записаться

В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты СА 🛠



В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩

👉 Это самая весомая и “программистская” часть вашего профессионального портфолио.



🎁 По заявкам до 22 апреля дарим дополнительное обучение по БД+SQL в подарок + самые выгодные условия.


Есть вопросы?
Пишите @getanalyst,
на почту info@getanalyst.ru
или заполняйте анкету предзаписи на сайте.
Мы поможем оценить ваши текущие навыки, пришлем дополнительную информацию и ответим на все вопросы 🤝

🤖 Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать 🤖

В новом эпизоде подкаста GetAnalyst вы найдёте обзор основных AI-инструментов для системных аналитиков. Разберётесь, чем они отличаются, какие возможности предлагают, что и для каких задач подходит лучше всего.

Ключевые нейросети в обзоре:
🤖 ChatGPT
🤖 DeepSeek
🤖 Gemini
🤖 YandexGPT

Также расскажем про дополнительные инструменты со встроенными AI-возможностями и про вспомогательное ПО, которое помогает системным аналитикам использовать нейросети с максимальной пользой.


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

🔗 Статья к эпизоду с дополнительными материалами


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

👉 Реальные кейсы, примеры и личный опыт.

Подкаст, который точно стоит послушать сегодня!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Получай самые актуальные знания с GetAnalyst — сообществом, где системные аналитики растут каждый день 📈

🐞 Виды HTTP-методов: не повторяйте эти ошибки 🐞

GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.

Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).


Основные HTTP-методы, которые нужно знать при проектировании REST API 👇


✅ POST: создание нового ресурса
Добавить новый товар в Интернет-магазин
Зарегистрировать пользователя
Создать заказ товаров
👉 Иногда POST может использоваться для получения данных:
+ асинхронные запросы
+ слишком много query-параметров (фильтров) для списков


✅ GET: получение ресурсов
Посмотреть список товаров
Получить информацию о выбранном товаре
Проверить статус заказа


✅ PUT: обновление ресурса целиком или создание нового
для полной замены данных ресурса

Вызываем PUT (изменить/создать) для товара со штрихкодом 0123456789, на вход передаём все-все данные о нём:
👉 если товар с таким штрихкодом уже был создан, то обновить данные по нему в БД целиком, даже если какие-то параметры, как название или стоимость менять сейчас не нужно
👉 если товар с таким штрихкодом еще не создан, то создать новый

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



✅ PATCH: частичное обновление ресурса
для обновления только некоторых полей ресурса - частичное редактирование.
Изменить описание товара и передать на вход методу только его.
При этом действии в БД поменяется только описание товара, и не будет полной перезаписи всех полей, как это происходит при использовании PUT.


✅ DELETE — удаление ресурса
Удалить выбранный товар из магазина
Удалить выбранный товар из заказа


🐞 Распространенные ошибки при выборе HTTP-методов для REST API на картинке к посту


Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.

#RestApiGA

💡 Иногда просто не хватает одного действия… и немного вдохновения 💡

Хочу поделиться историями входа в профессию аналитиков.
Они из реальной жизни моих знакомых и очень вдохновляют.

🤝 А ещё они показывают, насколько важно быть открытым к переменам и ценить силу хорошего нетворкинга.

#1. Иногда, чтобы изменить свою жизнь, нужно просто помнить чей-то заказ

Девушка работала бариста: делала смузи в баре при дорогом спортзале. Не училась в колледже, просто работала.

Однажды зашёл яркий мужчина и заказал крайне сложный, кастомный смузи — из серии “вот это, но без этого, и добавьте щепотку вот этого, но только если...”.
Необычный рецепт она запомнила, да и самого мужчину тоже.

Когда он пришёл в следующий раз, она повторила заказ по памяти прежде чем он успел что-то сказать.
Он был в шоке и спросил “Кто ты?!” 😂
Завязался разговор.

Чуть позже он представил её своей жене, которая занимается в том же зале, и предложил с ней побеседовать.

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

Она — вообще ни разу не айтишник. Просто быстро схватывает.

Сначала она думала: "Зачем мне это, я же просто делаю смузи, что я там буду делать без знаний?".
Но в итоге согласилась.

Сейчас она системный аналитик. Обожает свою работу. Обсуждали с ней подходы к написанию требований и процессы работы её команды. Толковый специалист.

И да, всё это началось с одного нестандартного заказа 🍹

#2. Бухгалтерия устала

Больше 8 лет она считала чужие налоги. Гибридная работа: в офисе и дома. Но постоянный стресс. Сроки. Отчетность. Куча нудных цифр.

Все повышения получены. Драйва в работе больше нет. Неинтересно, некуда расти.

Можно было сменить фирму и вырасти в деньгах. Но что изменилось бы? Радости к работе это бы не добавило.

Она решила попробовать себя в IT.
Только начала учебу, но что-то пошло не по плану.
Почти сразу после начала обучения она получила оффер в IT-компанию 🙃

Не магия, а совпадение. Её знакомый работает в ТОП-овой компании, которая делает ПО для ведения бухгалтерии. Им как раз был нужен кто-то из отрасли, кто понимает боль клиентов и может помочь им развивать продукт.

Когда он узнал, что она хочет в IT, то… На собеседование она попала быстро.

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


А ещё …

# Из отвечающего за бумажки в гос конторе до БА, с возможностью роста в СА.

# Из учителя в школе до СА.

Разные истории.
Разные люди, разные старты, разные решения.

👉 А суть такова: перемены — это не страшно, а вселенная всегда помогает нам.

Иногда всё, что нужно — вдохновение и первый шаг.
А дальше начнёт складываться.


👉 Если вам нужен знак, что всё возможно — вот он.
Главное быть смелым и открытым миру.

🤖 Нейросети для проектирования БД и SQL-запросов | Четверг, 19:00 Мск 🤖

В этот четверг будем на практике разбираться, как эффективно использовать нейросети для проектирования БД и выполнения SQL-запросов.


🟢 Использование ChatGPT (и не только) для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
🔗 Подробности и запись


В результате практикума:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с базами данных.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.


✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎

По вопросам можно писать через сайт или @getanalyst 💬


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

💎 Headers в REST API: что это и зачем 💎

Headers – заголовки запроса и ответа в протоколе HTTP.

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

Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.


Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим методам REST API 🙂


📌 Request Headers - для запросов

◽️ Authorization
Используется для передачи токенов доступа, ключей API или других данных для авторизации. Используется для проверки доступа к API-методам.

Authorization: Bearer <token>

◽️ Content-Type
Сообщает серверу, в каком формате отправлены данные.
Если сервер не знает в каком формате переданы данные, то он не сможет обработать запрос.
Если его нет в API, то сервер обычно ждёт JSON, если в документации не указано иное.

Content-Type: application/json

Content-Type: application/xml

◽️ Cache-Control
Управляет кэшированием данных на клиенте.
Полезно для работы с экономией трафика.

Cache-Control: no-cache

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

Idempotency-Key: <unique-key>

◽️ Часовые пояса
Когда система работает в разных регионах, важно учитывать часовые пояса и их можно передавать как обязательные заголовки во всех запросах.
Стандартные названия из моего опыта:

Time-Zone: UTC+3

X-Time-Zone: UTC+3

📌 + помним про Response Headers (заголовки ответов)


Полные подборки стандартных Headers:
🔗 Wikipedia
🔗 MDN


Правильно выбранные Headers помогают удобно передавать все системные параметры для обмена данными, которые не важны для бизнес-логики и алгоритмов работы API-методов.

#RestApiGA

☑️ Проверьте свои знания: как строить эндпоинты для REST API методов ✅

Разобрали:
🔗HTTP-методы
🔗Структура URL
🔗Пагинация

Попробуйте ответить на вопросы, а затем сравнить результаты с предложенными ответами 👇

1. Какой метод и URL использовать для добавления нового продукта с КБЖУ?
❌ POST /createProduct
→ В URL дублируется действие, хотя оно уже обозначено методом POST
✅ POST /products
→ Метод POST = создание, /products — имя сущности (ресурса), которым управляем


2. Какой эндпоинт нужен для создания рецепта конкретным пользователем?
❌ POST /recipes/{userId}
→ Ресурс recipes не вложен внутрь userId, иерархия нарушена
▫️ POST /recipes?userId={userId}
→ Можно, но есть вариант лучше
▫️ POST /users/{userId}/recipes
→ Аналогично
✅ POST /recipes
с авторизацией пользователя в заголовке header запроса
→ Кто автор — понятно из токена, userId не нужен в URL. В двух вариантах выше не лучшее решение, т.к. по факту получается, что есть дублирование id пользователя в запросе


3. Как изменить обложку (фото) рецепта с id = 45?
❌ PUT /recipes/45/changeCover
→ Избыточный глагол в URL, лучше обозначить действие через PATCH
✅ PATCH /recipes/45/cover
→ PATCH подходит для частичного изменения (только обложки). Это конкретный эндпоинт для загрузки нового изображения
✅ PATCH /recipes/45
с телом { "coverUrl": "..." }
→ Если есть отдельный метод POST /images на загрузку изображений в файловое хранилище, из которого можно получить url для подстановки в "coverUrl"


4. Как удалить продукт из справочника?
❌ PATCH /deleteProduct/15
→ Действие должно быть в глаголе HTTP - DELETE
▫️ DELETE /products?productId=15
→ Есть вариант лучше
✅ DELETE /products/15
→ Лучший вариант
✅ PATCH /products/15/archive
→ Если хотим архивировать - удалить с возможностью восстановления


5. Как удалить продукт из рецепта (ингредиент)?
❌ DELETE /products/15
→ Это удалит сам продукт, а не его использование в рецепте
✅ DELETE /recipes/8/ingredients/15
→ Соблюдена иерархия


Какие ещё варианты у вас получились? Есть вопросы? Пишите комментарии 📝👍

#RestApiGA #RecipeGA

📍 5 ошибок в дизайне REST API | Открытый вебинар 24 апреля 📍

Аналитики встречаются с REST API постоянно.

И если говорить о создании API-методов "с нуля", то вроде бы всё понятно:
выбирай правильные HTTP методы, делай URL по аналогии, описывай запросы и ответы в JSON.

Но на практике — сплошные нюансы.

Даже опытные аналитики делают ошибки:
➖ добавляют глаголы в URL,
➖ путают уровни иерархии,
➖ описывают JSON, на которые "ворчат" разработчики,
➖ не думают о поддержке и обратной совместимости.
И на собеседованиях — те же грабли 😔


Чтобы познакомить вас с проектированием REST API и одновременно прокачать в понимании всех "подводных камней" работы, мы готовим для вас новый практический вебинар:


🐞 5 ошибок в дизайне REST API:
👉 примеры реальных задач с проектов и собеседований
🗓 24 апреля (чт), 19:00 Мск

🔗 Подробности и регистрация


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


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

Присоединяйтесь онлайн и получайте новый опыт! 🙌

⚡️🐇 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 🐇⚡️

Знакомимся с брокером RabbitMQ: как он работает, когда применяется, и чем принципиально отличается от Kafka, чтобы вы могли уверенно выбирать решение под задачи проекта.

🔗 Презентация и шаблон постановки задачи

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

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video
⏯ Telegram

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Spotify

Подписывайтесь на GetAnalyst, чтобы каждый день получать новый опыт в системном анализе! ⚡️

🌱 Что бы я сказала себе, если бы только начинала карьеру Системного Аналитика? 🌱
А если честно, я это и сейчас себе постоянно напоминаю...

📍 Не бойся задавать вопросы — особенно «глупые».
Ты не обязана знать всё.
Но если стесняешься спросить, то будешь делать вид, что поняла, а потом зависнешь одна, сделаешь ошибки или по 100 раз будешь перепроверять информацию.

📍 Ты не обязана делать всё идеально с первого раза.
Ты учишься. И будешь учиться всегда. Даже через 10 лет, когда уже будешь сама вести проекты, руководить компанией, менторить других и объяснять архитектуру клиенту — всё равно будут моменты «погоди, а как это вообще работает?»

📍 Структура — это суперсила.
В хаосе требований, встреч, срочных задач и непонятных ролей умение выделить главное, собрать картину целиком и объяснить другим — бесценно!
И этому можно научиться. Не сразу. Но можно.

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

📍 Окружение решает.
Рядом с людьми, которые не боятся спрашивать, не стыдно учиться.
С теми, кто делится опытом, — расти быстрее.
В среде, где нормально чего-то не знать, но хотеть разобраться — формируется уверенность.


✨ Сегодня я стараюсь создать именно такую среду в GetAnalyst — международном сообществе системных и бизнес-аналитиков.

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


💚 На каком бы этапе в карьере вы ни были, помните, вы не одни на этом пути.

Я прошла этот путь — с сомнениями, с радостями, с трудными моментами.
🌱 И продолжаю идти дальше, потому что рост не заканчивается.

Моя миссия — помогать вам уверенно развиваться в нашей одновременно и технической, и творческой профессии. С уверенностью, опорой и пониманием, зачем и куда двигаться.

Искренне ваша,
Екатерина Ананьева 💚

⚡ Заканчивается предзапись на REST API с 6 мая ⚡

Актуально добавить знания и опыт по REST API в резюме и портфолио? Хотите с легкостью осваивать другие API за счет глубокого понимания работы протокола HTTP? Тогда рекомендую посмотреть нашу практическую программу:

💻 Дизайн REST API
🗓 Старт: 6 мая 2025
👥 Первая встреча: 13 мая 2025

Вас ждёт:
⚡️ 9 онлайн-встреч
⚡️ 6 месяцев доступа к материалам
⚡️ Telegram-чат с индивидуальной обратной связью для всех участников
⚡️ QA-сессия для разбора вопросов по вашим проектам (ДЗ)

Результат - личный проект портфолио:
✅ Постановки задач и документация в Confluence
✅ Postman-коллекции и интерактивная API-документация
✅ Swagger-документация
✅ Работающие на загрушках ваши API-методы (mock api)

✅ Возможность развиваться, чтобы работать в Backend-командах, на проектах с мобильными приложениями и интеграциями, где аналитики глубоко погружаются в техническое проектирование и создают контракты REST API

🔗 Узнать подробнее и оставить заявку


⌛️ Только до 22 апреля:
Дополнительное обучение по БД+SQL в подарок и запись на самых выгодных условиях.


Есть вопросы? Пишите в @getanalyst или заполняйте анкету на сайте.
Поможем оценить ваш текущий уровень и подскажем, подойдёт ли вам программа 🤝

📚 Всё про JSON в одной картинке 📚

JSON - основной формат сообщений, который используется для обмена данными в разработке ПО:

✔️ REST API (запросы и ответы)
✔️ GraphQL (ответы)
✔️ Сообщения для брокеров Kafka / RabbitMQ
✔️ и в других случаях.


Инструменты, которые помогут в работе и на собеседованиях, когда вас спрашивают о JSON:

🔗 jsoneditoronline
🔗 postman
🔗 chatgpt / deepseek и другие нейросети


А всё остальное, включая подробный разбор структуры JSON, типичные ошибки и рекомендации по проектированию, собрала для вас в практическом руководстве, прикрепленном к посту 📚

#RestApiGA #RecipeGA

🔥 Открытый практикум 24 апреля: знакомимся с REST API через Postman + фишки AI + разбор ошибок проектирования 🔥

Лучше всего изучать теорию через практику. Особенно это касается REST API!
Ведь именно благодаря его глубокому пониманию все остальные API, такие как GraphQL и gRPC, даваться будут гораздо легче 🙌


Поэтому готовлю новый практикум, и уже в этот четверг, буду погружать вас в REST API на примерах реальных задачах с проектов и собеседований:

🔥 5 ошибок в дизайне REST API
🗓 24 апреля (чт), 19:00 Мск
👉 Подробности и регистрация

План:
1. Знакомство с REST API на практике - через Postman
2. Разбор 5 ошибок проектирования REST API
3. Шаблон постановки задачи на разработчиков

Инструменты:
✅ Postman
✅ Консоль браузера
✅ Figma с дизайном UI/UX
✅ dbdiagram.io со схемой БД (ER-диаграмма)
✅ ChatGPT для ускорения работы


Подготовка:
Перед эфиром установите Postman, попробуйте сделать Workspace и первую коллекцию по инструкции. Всё остальное покажем онлайн.
Инструкция по Postman с нуля

Реальная работа и серьёзная аналитика.
Будем погружаться в сложную теорию через разбор конкретных примеров.


До встречи онлайн, в этот четверг! 😊