🐞 Разбор квиза по REST API - ошибки, которые допускают из-за отсутствия насмотренности и опыта 🐞
Пару дней назад я опубликовала вопросы с подвохами по REST API.
✅ Результаты тут
Как всегда, вижу сильный перекос голосов в сторону:
«а давайте всё сделаем через POST» 🙃
Но прежде чем вы начнёте спорить в комментариях, хочу сразу показать простой CRUD на примере управления данными о записи на приём к ветеринару.
Если это HTTP API без REST-подхода, то может получиться так:
Почему это не REST?
❌ В URL используются глаголы, хотя их роль уже могут выполнять HTTP-методы: GET, POST, PUT, PATCH, DELETE.
Если делаете REST API, то запись того же CRUD будет выглядеть так:
Почему это ближе к REST?
✅ В URL нет лишних глаголов.
✅ Действие определяется HTTP-методом.
✅ URL описывает ресурс, а не команду.
*public — это название API. Его можно опустить, но на практике часто полезно сохранять, особенно в микросервисной архитектуре.
❗️Главное правило перед проектированием эндпоинтов RESTful API:
сначала распишите полный набор операций для одного ресурса по CRUD и проверьте, чтобы не было конструкций вроде: POST /objects/create.
Потому что здесь уже возникает дублирование смысла: POST = create, а create ещё раз написан в URL.
Итого, ключевые ошибки в тестировании:
👉 1. Запись на приём
Большинство выбрали верный вариант.
Но много голосов было и за:
❌ POST /appointments/create - это "масло-маслянное"
❌ POST /appointments/{id} - откуда возьмете id? он же присваивается после создания записи на сервере, в БД
👉 2. История записей
По сути это обычное получение списка записей на приём.
Большинство выбрали корректные варианты, но здесь важно помнить ещё одну вещь:
❗️В идеале нужно было в предложенных решениях добавить названия API:
А я их благополучно скрыла от вас.
👉 3. Отмена записи
За DELETE - большинство голосов.
Но отмена записи — это чаще не удаление строки из БД, а изменение статуса.
Поэтому более точный вариант здесь — PATCH, если мы, например, меняем статус записи на cancelled.
DELETE иногда тоже встречается, но с точки зрения бизнес-смысла PATCH здесь обычно аккуратнее.
📌 Почему "все POST" это не REST?
“всё через POST” не доказывает автоматически, что API не REST,
но очень часто означает, что API игнорирует стандартную семантику HTTP и уходит в сторону RPC over HTTP — этот вывод следует из сочетания RFC 9110 и диссертации Филдинга
▫️ HTTP требует уважать семантику методов — RFC 9110
▫️ REST определяется наличием uniform interface и hypermedia constraints — Филдинг, 5.1.5 - “REST APIs must be hypertext-driven”.
Подробный разбор каждого варианта — на картинках к посту 🤝
🖼 Исходники картинок
Полезные материалы, связанные с решением:
📚 Шпаргалка по методам: GET, POST, PUT, PATCH, DELETE
📚 Примеры API с разбором структуры методов
📚 Структура URL в REST API
🩵 Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
Пример HTTP API:
https://www.unisender.com/ru/support/api/common/bulk-email/
Пример REST API:
https://developers.avito.ru/api-catalog/job/documentation#operation/applicationsGetIds
#RestApiGA #VetCareGA (Tg | ВК | Max)
Пару дней назад я опубликовала вопросы с подвохами по REST API.
✅ Результаты тут
Как всегда, вижу сильный перекос голосов в сторону:
«а давайте всё сделаем через POST» 🙃
Но прежде чем вы начнёте спорить в комментариях, хочу сразу показать простой CRUD на примере управления данными о записи на приём к ветеринару.
Если это HTTP API без REST-подхода, то может получиться так:
POST /api/public/v1/appointments/create - создать запись
POST /api/public/v1/appointments/{id} - получить запись по id
POST /api/public/v1/appointments/list - получить список записей
POST /api/public/v1/appointments/{id}/update - редактировать запись (отменить)
POST /api/public/v1/appointment/{id}/delete - удалить запись
Почему это не REST?
❌ В URL используются глаголы, хотя их роль уже могут выполнять HTTP-методы: GET, POST, PUT, PATCH, DELETE.
Если делаете REST API, то запись того же CRUD будет выглядеть так:
POST /api/public/v1/appointments - создать запись
GET /api/public/v1/appointments/{id} - получить запись по id
GET /api/public/v1/appointments - получить список записей, не конкретная по id
PATCH /api/public/v1/appointments/{id} - редактировать запись (отменить)
DELETE /api/public/v1/appointments/{id} - удалить запись
Почему это ближе к REST?
✅ В URL нет лишних глаголов.
✅ Действие определяется HTTP-методом.
✅ URL описывает ресурс, а не команду.
*public — это название API. Его можно опустить, но на практике часто полезно сохранять, особенно в микросервисной архитектуре.
❗️Главное правило перед проектированием эндпоинтов RESTful API:
сначала распишите полный набор операций для одного ресурса по CRUD и проверьте, чтобы не было конструкций вроде: POST /objects/create.
Потому что здесь уже возникает дублирование смысла: POST = create, а create ещё раз написан в URL.
Это минимальное, чтобы уйти от HTTP API в сторону REST-а.
Итого, ключевые ошибки в тестировании:
👉 1. Запись на приём
Большинство выбрали верный вариант.
Но много голосов было и за:
❌ POST /appointments/create - это "масло-маслянное"
❌ POST /appointments/{id} - откуда возьмете id? он же присваивается после создания записи на сервере, в БД
👉 2. История записей
По сути это обычное получение списка записей на приём.
Большинство выбрали корректные варианты, но здесь важно помнить ещё одну вещь:
❗️В идеале нужно было в предложенных решениях добавить названия API:
/api/admin/v1
/api/public/v1
А я их благополучно скрыла от вас.
👉 3. Отмена записи
За DELETE - большинство голосов.
Но отмена записи — это чаще не удаление строки из БД, а изменение статуса.
Поэтому более точный вариант здесь — PATCH, если мы, например, меняем статус записи на cancelled.
DELETE иногда тоже встречается, но с точки зрения бизнес-смысла PATCH здесь обычно аккуратнее.
📌 Почему "все POST" это не REST?
“всё через POST” не доказывает автоматически, что API не REST,
но очень часто означает, что API игнорирует стандартную семантику HTTP и уходит в сторону RPC over HTTP — этот вывод следует из сочетания RFC 9110 и диссертации Филдинга
▫️ HTTP требует уважать семантику методов — RFC 9110
▫️ REST определяется наличием uniform interface и hypermedia constraints — Филдинг, 5.1.5 - “REST APIs must be hypertext-driven”.
Подробный разбор каждого варианта — на картинках к посту 🤝
🖼 Исходники картинок
Полезные материалы, связанные с решением:
📚 Шпаргалка по методам: GET, POST, PUT, PATCH, DELETE
📚 Примеры API с разбором структуры методов
📚 Структура URL в REST API
🩵 Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
Пример HTTP API:
https://www.unisender.com/ru/support/api/common/bulk-email/
Пример REST API:
https://developers.avito.ru/api-catalog/job/documentation#operation/applicationsGetIds
#RestApiGA #VetCareGA (Tg | ВК | Max)
❤20🔥9⚡4🤩1
This media is not supported in your browser
VIEW IN TELEGRAM
Старенькая серия саус-парка про Интернет… сегодня уже не так смешно 🥲📡
1😁38😢16🤣5💯3🔥2
🩵 REST API vs GraphQL - сравнение с примерами 🩷
Последний вопрос в тесте показал, что с GraphQL знакомы пока немногие.
Либо часть из вас просто не заметила, что вопрос был именно про GraphQL, а не про REST API 🙂
👉 Вопрос был такой:
Какой endpoint выбрать для получения карточки питомца в GraphQL?
Большинство голосов ушло за вариант, который был бы верным для REST API:
Но в GraphQL логика другая.
🩷 GraphQL — это другой подход к проектированию API по сравнению с REST.
Что важно понимать:
✔️ GraphQL обычно работает поверх HTTP
✔️ чаще всего используется один endpoint: POST /graphql
✔️ для запросов только на получение данных также может использоваться GET /graphql
✔️ клиент сам указывает, какие поля хочет получить в ответе
✔️ это помогает не получать лишние данные и в ряде случаев экономить трафик
✔️ ошибки в GraphQL часто возвращаются внутри JSON-ответа в поле errors, при этом HTTP-статус остаётся 200
🩵🩷 Подробное сравнение GraphQL с REST API я показала на примере метода
«Создать запись на приём к ветеринару» — смотрите на картинках к посту.
И отдельно правильный ответ на вопрос из теста про «Получение карточки питомца»:
👉 POST /graphql — основной вариант эндпоинта
👉 GET /graphql — тоже допустим, если это только запрос на получение данных
В этом и был подвох:
в REST API мы обычно проектируем отдельные endpoint-ы под разные сценарии,
а в GraphQL чаще всего работаем через один общий endpoint.
#RestApiGA #VetCareGA
📱 Tg | 💙 ВК | 💬 Max
Последний вопрос в тесте показал, что с GraphQL знакомы пока немногие.
Либо часть из вас просто не заметила, что вопрос был именно про GraphQL, а не про REST API 🙂
👉 Вопрос был такой:
Какой endpoint выбрать для получения карточки питомца в GraphQL?
Большинство голосов ушло за вариант, который был бы верным для REST API:
GET /api/v1/pets/{petId}
Но в GraphQL логика другая.
🩷 GraphQL — это другой подход к проектированию API по сравнению с REST.
Что важно понимать:
✔️ GraphQL обычно работает поверх HTTP
✔️ чаще всего используется один endpoint: POST /graphql
✔️ для запросов только на получение данных также может использоваться GET /graphql
✔️ клиент сам указывает, какие поля хочет получить в ответе
✔️ это помогает не получать лишние данные и в ряде случаев экономить трафик
✔️ ошибки в GraphQL часто возвращаются внутри JSON-ответа в поле errors, при этом HTTP-статус остаётся 200
🩵🩷 Подробное сравнение GraphQL с REST API я показала на примере метода
«Создать запись на приём к ветеринару» — смотрите на картинках к посту.
И отдельно правильный ответ на вопрос из теста про «Получение карточки питомца»:
👉 POST /graphql — основной вариант эндпоинта
👉 GET /graphql — тоже допустим, если это только запрос на получение данных
В этом и был подвох:
в REST API мы обычно проектируем отдельные endpoint-ы под разные сценарии,
а в GraphQL чаще всего работаем через один общий endpoint.
#RestApiGA #VetCareGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤24🔥5👍2🦄2😁1
📌 Проси много, чтобы получить хотя бы половину 📌
Это моя фраза недели.
Мне кажется, она очень хорошо ложится не только на бизнес, но и на карьеру, зарплату и профессиональный рост.
Мы часто сами себя занижаем:
▫️ «мне ещё рано»
▫️ «я пока не дотягиваю»
▫️ «а вдруг откажут»
▫️ «а вдруг я прошу слишком много»
Особенно сейчас, когда вокруг много тревоги, нестабильности и разговоров про кризис.
А потом удивляемся, почему нас оценивают ниже, чем хотелось бы?!
Иногда рост начинается не с нового курса, новой работы или нового проекта.
👉 А с внутреннего разрешения перестать торговаться против себя.
Просить больше.
Называть сумму смелее.
Не обесценивать свой опыт.
Не объяснять себе самому заранее, почему вам можно заплатить меньше.
Потому что если вы сами ставите себе нижнюю планку, рынок редко будет спорить и поднимать её за вас.
👉 Рост часто начинается там, где вы перестаёте себя уменьшать.
И если вы хотя читаете этот канал, думаете о профессии, задаёте вопросы, учитесь и развиваетесь — это уже не «ничего особенного».
Это уже вклад в вашу будущую стоимость как специалиста.
P.S. А к посту добавила подборку доброты, которая скопилась за последние пару месяцев. Здесь поместилось меньше половины 🩷🩷🩷 Огромная благодарность за каждое сообщение 🙏
📱 Tg | 💙 ВК | 💬 Max
Это моя фраза недели.
Мне кажется, она очень хорошо ложится не только на бизнес, но и на карьеру, зарплату и профессиональный рост.
Мы часто сами себя занижаем:
▫️ «мне ещё рано»
▫️ «я пока не дотягиваю»
▫️ «а вдруг откажут»
▫️ «а вдруг я прошу слишком много»
Особенно сейчас, когда вокруг много тревоги, нестабильности и разговоров про кризис.
А потом удивляемся, почему нас оценивают ниже, чем хотелось бы?!
Иногда рост начинается не с нового курса, новой работы или нового проекта.
👉 А с внутреннего разрешения перестать торговаться против себя.
Просить больше.
Называть сумму смелее.
Не обесценивать свой опыт.
Не объяснять себе самому заранее, почему вам можно заплатить меньше.
Потому что если вы сами ставите себе нижнюю планку, рынок редко будет спорить и поднимать её за вас.
👉 Рост часто начинается там, где вы перестаёте себя уменьшать.
И если вы хотя читаете этот канал, думаете о профессии, задаёте вопросы, учитесь и развиваетесь — это уже не «ничего особенного».
Это уже вклад в вашу будущую стоимость как специалиста.
P.S. А к посту добавила подборку доброты, которая скопилась за последние пару месяцев. Здесь поместилось меньше половины 🩷🩷🩷 Огромная благодарность за каждое сообщение 🙏
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥25💯9🦄7❤2🔥1
GetAnalyst_Параметры_в_запросах_REST_API_HTTP.png
2.2 MB
✍️ 3 вида параметров HTTP, где чаще всего ошибаются аналитики ✍️
Гайд по параметрам HTTP (REST API) запросов, в которых чаще всего путаются новички:
👉 query — после ? в URL.
Используются для:
+ фильтров,
+ сортировки,
+ пагинации (limit+offset),
+ api-key (если так принято).
Получить список пользователей с именем "Иван", 10 записей, начиная с 20-ой, сортировать по алфавиту А -> Я.
Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо использования тела json.
• Добавляют query в POST/PUT без причины.
👉 path — часть пути (эндпоинта).
Идентификатор конкретного ресурса.
Можно внутри пути, когда иерархия:
Типичные проблемы:
• Отправляют ?userId=… в query, хотя это выбор сущности по id, а не фильтр.
👉 body — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.
Типичные проблемы:
• Отправляют огромное количество параметров в query, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body(json) для GET или DELETE, где оно не поддержано.
В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры
Изучайте, запоминайте и не путайтесь 🤝
#RestApiGA
📱 Tg | 💙 ВК | 💬 Max
Гайд по параметрам HTTP (REST API) запросов, в которых чаще всего путаются новички:
👉 query — после ? в URL.
Используются для:
+ фильтров,
+ сортировки,
+ пагинации (limit+offset),
+ api-key (если так принято).
GET /users?name=Иван&limit=10&offset=20&order=name,asc
Получить список пользователей с именем "Иван", 10 записей, начиная с 20-ой, сортировать по алфавиту А -> Я.
Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо использования тела json.
• Добавляют query в POST/PUT без причины.
👉 path — часть пути (эндпоинта).
Идентификатор конкретного ресурса.
GET /users/{userId}
→ GET /users/12345
Можно внутри пути, когда иерархия:
PATCH /users/{userId}/archive
Типичные проблемы:
• Отправляют ?userId=… в query, хотя это выбор сущности по id, а не фильтр.
👉 body — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.
{
"name": "Петр",
"lastname": "Иванов",
"bio": "Любитель системного анализа"
}
Типичные проблемы:
• Отправляют огромное количество параметров в query, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body(json) для GET или DELETE, где оно не поддержано.
В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры
Изучайте, запоминайте и не путайтесь 🤝
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19🔥3⚡1👍1
🤔 Разница в HTTP, REST и RESTful API 🤔
Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀
Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:
1️⃣ API — это программный интерфейс для обмена данными между приложениями:
• мобильное приложение ↔ сервер
• сайт ↔ сервер
• один backend-сервис ↔ другой backend-сервис
• внутренняя система ↔ внешняя система
API определяет, как одна система может обратиться к другой: какие запросы отправлять, какие данные передавать и какие ответы получать.
2️⃣ HTTP — это один из основных протоколов обмена данными в Интернете.
Он определяет, как клиент и сервер обмениваются сообщениями:
• клиент отправляет запрос
• сервер обрабатывает его
• сервер возвращает ответ
HTTP включает:
• методы: GET, POST, PUT, PATCH, DELETE и другие
• статус-коды: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и другие
• заголовки
• тело запроса и ответа
Важно: HTTP сам по себе ещё не делает API REST API.
Можно сделать HTTP API, где все методы будут через POST, с глаголами в URL и без нормальной ресурсной модели.
Например:
Это будет HTTP API, но не REST API.
3️⃣ REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API.
Проще говоря, REST задаёт подход:
как правильно организовать взаимодействие клиента и сервера через ресурсы.
В REST данные представляются как ресурсы.
Например:
С этими ресурсами выполняются действия через HTTP-методы:
То есть мы не пишем действие в URL, а используем связку:
Если этот принцип не соблюдается, то это чаще просто HTTP API, а не REST API.
4️⃣ REST API — архитектурный стиль проектирования программных интерфейсов.
Такой API:
• работает с ресурсами
• использует HTTP-методы по смыслу
• адресует ресурсы через URL
• возвращает данные в удобном для клиента формате, чаще всего JSON
• использует HTTP-статусы для описания результата операции
Пример:
5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST.
То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в REST.
Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.
👉 По сути
HTTP — это протокол передачи данных.
REST — архитектурный стиль.
REST API — API, сделанный по принципам REST.
RESTful API — API, который подчёркнуто следует REST-подходу.
👉 В повседневной разработке эти различия зачастую стираются, и термины используются как синонимы.
Но на собеседовании лучше показать, что вы понимаете разницу:
🔹 не любой HTTP API является REST API,
🔹 но REST API обычно использует HTTP.
Желаю вам успешных технических собеседований 😉
#RestApiGA
Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀
Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:
1️⃣ API — это программный интерфейс для обмена данными между приложениями:
• мобильное приложение ↔ сервер
• сайт ↔ сервер
• один backend-сервис ↔ другой backend-сервис
• внутренняя система ↔ внешняя система
API определяет, как одна система может обратиться к другой: какие запросы отправлять, какие данные передавать и какие ответы получать.
2️⃣ HTTP — это один из основных протоколов обмена данными в Интернете.
Он определяет, как клиент и сервер обмениваются сообщениями:
• клиент отправляет запрос
• сервер обрабатывает его
• сервер возвращает ответ
HTTP включает:
• методы: GET, POST, PUT, PATCH, DELETE и другие
• статус-коды: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и другие
• заголовки
• тело запроса и ответа
Важно: HTTP сам по себе ещё не делает API REST API.
Можно сделать HTTP API, где все методы будут через POST, с глаголами в URL и без нормальной ресурсной модели.
Например:
POST /createUser
POST /getUserInfo
POST /deleteUser
Это будет HTTP API, но не REST API.
3️⃣ REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API.
Проще говоря, REST задаёт подход:
как правильно организовать взаимодействие клиента и сервера через ресурсы.
В REST данные представляются как ресурсы.
Например:
/users
/users/{userId}
/orders
/orders/{orderId}
С этими ресурсами выполняются действия через HTTP-методы:
GET /users/{userId}
POST /users
PUT /users/{userId}
PATCH /users/{userId}
DELETE /users/{userId}
То есть мы не пишем действие в URL, а используем связку:
HTTP-метод + ресурс
Если этот принцип не соблюдается, то это чаще просто HTTP API, а не REST API.
4️⃣ REST API — архитектурный стиль проектирования программных интерфейсов.
Такой API:
• работает с ресурсами
• использует HTTP-методы по смыслу
• адресует ресурсы через URL
• возвращает данные в удобном для клиента формате, чаще всего JSON
• использует HTTP-статусы для описания результата операции
Пример:
GET /api/v1/products
GET /api/v1/products/{productId}
POST /api/v1/products
PATCH /api/v1/products/{productId}
DELETE /api/v1/products/{productId}
5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST.
То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в REST.
Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.
👉 По сути
HTTP — это протокол передачи данных.
REST — архитектурный стиль.
REST API — API, сделанный по принципам REST.
RESTful API — API, который подчёркнуто следует REST-подходу.
👉 В повседневной разработке эти различия зачастую стираются, и термины используются как синонимы.
Но на собеседовании лучше показать, что вы понимаете разницу:
🔹 не любой HTTP API является REST API,
🔹 но REST API обычно использует HTTP.
Желаю вам успешных технических собеседований 😉
#RestApiGA
🔥14👍7❤4
🔥 19 мая — последний онлайн-поток по REST API перед годовым перерывом 🔥
Открываем предзапись на практическую программу для системных и бизнес-аналитиков:
📌 Дизайн REST API
🗓 Старт — 19 мая 2026
🎁 Лучшие условия действуют только до 12 мая:
✅ сниженная стоимость участия
✅ мини-курс по Архитектуре в подарок
✅ +1 дополнительный месяц доступа к материалам курса
🔗 Узнать подробности и записаться
Это последний живой поток в этом году. Следующий в мае 2027 года.
Мы переходим к формату, где живое обучение по REST API будет проходить 1 раз в год.
В течение года курс можно будет проходить самостоятельно по записям.
👉 По сути, это последний шанс в этом году пройти REST API в полном формате: с живыми занятиями, практикой, обратной связью, разбором ошибок и возможностью задавать вопросы.
На программе учимся проектировать REST API так, как это нужно системному аналитику в реальной работе:
▫️ выбирать GET / POST / PUT / PATCH / DELETE
▫️ проектировать URL, path/query-параметры, headers и JSON body
▫️ описывать HTTP-коды и обработку ошибок
▫️ работать с Postman, Insomnia, Swagger / OpenAPI
▫️ описывать авторизацию и требования к API
▫️ готовить постановки задач для backend-разработчиков
✅ По итогам: собираете REST API-проект для портфолио
Это не курс “посмотреть видео про REST”.
Это практическое обучение, где вы руками проектируете API, разбираете ошибки и учитесь мыслить через ресурсы, контракты, сценарии и ограничения системы.
🟢 После основного онлайн-потока участникам будут доступны дополнительные ежемесячные встречи на сложные темы:
▫️ ИИ в работе с REST API
▫️ GraphQL после REST
▫️ кэширование в API
▫️ задачи к собеседованиям
▫️ дополнительные разборы практических кейсов
📌 Кому актуально:
✔️ если на работе вам уже прилетают задачи по API, но вы не до конца уверены в своих решениях
✔️ если на собеседованиях спрашивают REST, HTTP, JSON, Postman, Swagger, а ответы пока звучат неуверенно
✔️ если хотите перейти от “я примерно понимаю API” к “я могу сам спроектировать метод и описать его для разработки”
✔️ если хотите расти в backend: интеграции, микросервисы и архитектуру.
REST API — один из базовых технических навыков аналитика.
Без него сложно уверенно работать с интеграциями, backend и архитектурой систем.
Текущий поток — хороший момент закрыть эту тему системно: не отдельными статьями и кусками из разных источников, а через живую практику, проект, обратную связь и понятную структуру обучения 🤝
Нужна консультация по программе? Пишите в ЛС @getanalyst или через сайт💬
Открываем предзапись на практическую программу для системных и бизнес-аналитиков:
📌 Дизайн REST API
🎁 Лучшие условия действуют только до 12 мая:
✅ сниженная стоимость участия
✅ мини-курс по Архитектуре в подарок
✅ +1 дополнительный месяц доступа к материалам курса
Это последний живой поток в этом году. Следующий в мае 2027 года.
Мы переходим к формату, где живое обучение по REST API будет проходить 1 раз в год.
В течение года курс можно будет проходить самостоятельно по записям.
👉 По сути, это последний шанс в этом году пройти REST API в полном формате: с живыми занятиями, практикой, обратной связью, разбором ошибок и возможностью задавать вопросы.
На программе учимся проектировать REST API так, как это нужно системному аналитику в реальной работе:
▫️ выбирать GET / POST / PUT / PATCH / DELETE
▫️ проектировать URL, path/query-параметры, headers и JSON body
▫️ описывать HTTP-коды и обработку ошибок
▫️ работать с Postman, Insomnia, Swagger / OpenAPI
▫️ описывать авторизацию и требования к API
▫️ готовить постановки задач для backend-разработчиков
✅ По итогам: собираете REST API-проект для портфолио
Это не курс “посмотреть видео про REST”.
Это практическое обучение, где вы руками проектируете API, разбираете ошибки и учитесь мыслить через ресурсы, контракты, сценарии и ограничения системы.
🟢 После основного онлайн-потока участникам будут доступны дополнительные ежемесячные встречи на сложные темы:
▫️ ИИ в работе с REST API
▫️ GraphQL после REST
▫️ кэширование в API
▫️ задачи к собеседованиям
▫️ дополнительные разборы практических кейсов
📌 Кому актуально:
✔️ если на работе вам уже прилетают задачи по API, но вы не до конца уверены в своих решениях
✔️ если на собеседованиях спрашивают REST, HTTP, JSON, Postman, Swagger, а ответы пока звучат неуверенно
✔️ если хотите перейти от “я примерно понимаю API” к “я могу сам спроектировать метод и описать его для разработки”
✔️ если хотите расти в backend: интеграции, микросервисы и архитектуру.
REST API — один из базовых технических навыков аналитика.
Без него сложно уверенно работать с интеграциями, backend и архитектурой систем.
Текущий поток — хороший момент закрыть эту тему системно: не отдельными статьями и кусками из разных источников, а через живую практику, проект, обратную связь и понятную структуру обучения 🤝
Нужна консультация по программе? Пишите в ЛС @getanalyst или через сайт
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2