🔐 «Безопасный» и «идемпотентный» — что это значит для HTTP‑методов?

Когда на собеседовании спрашивают про безопасность и идемпотентность, речь не об HTTPS и не про авторизацию. Это про семантику методов — как они должны себя вести.

БЕЗОПАСНЫЕ методы
Метод считается безопасным, если он ничего не меняет на сервере, а только читает информацию.

✅ GET /users/123 Получить данные пользователя. Хоть тысячу раз повторяйте — состояние сервера останется прежним.
✅ HEAD /reports/2023 Проверить, есть ли отчёт за 2023 год. Возвращает только заголовки, без данных — ничего не изменится.
❌ POST /payments { "amount": 100 } Создаёт новый платёж → меняет данные на сервере, небезопасный.
❌ PUT /users/123 { "name": "Иван" } Изменяет имя пользователя → состояние данных поменялось, не безопасный.
❌ PATCH /users/123 { "email": "new_email@gmail.com" } Обновляет только email пользователя → данные на сервере изменяются, не безопасный.
❌ DELETE /orders/555 Удаляет заказ → меняет данные, значит не безопасный.

ИДЕМПОТЕНТНЫЕ методы
Идемпотентный метод — это когда повторный вызов с теми же параметрами даёт тот же результат, что и первый.

✅ GET /products/10 Хоть сколько раз вызывайте — всегда вернёт одни и те же данные товара.
✅ HEAD /products/10 Повторно возвращает только заголовки ресурса, результат не меняется.
✅ PUT /users/123 { "name": "Иван" } Каждый раз устанавливает имя пользователя на "Иван". Итоговое состояние всегда одинаковое.
✅ DELETE /orders/555 При первом вызове удалит заказ, повторно вернёт 404 — в итоге заказа нет, состояние не меняется.
❌ POST /payments { "amount": 100 } Каждый раз создаётся новый платёж → состояние сервера меняется при каждом вызове.
❌ PATCH /users/123 { "points": "+10" } Каждый повтор добавляет пользователю 10 баллов → состояние каждый раз новое.

Есть и другие методы (OPTIONS, CONNECT, TRACE), но они не влияют на изменение ресурсов и редко обсуждаются на интервью по REST API.

❗️ Запомнить просто:
Безопасный метод 👉 ничего не меняет на сервере, только чтение.
Идемпотентный метод 👉 повтор запроса не меняет итоговое состояние ресурса.

#api #rest #http #interview

⚙️ Как сделать POST-запрос идемпотентным?

На собеседованиях спрашивают про идемпотентность POST не для «галочки», а чтобы проверить, что вы понимаете реальные проблемы надёжности API.

❌ POST — не идемпотентный метод. Повторный вызов создаёт новый ресурс или действие. Например, если отправить форму платежа дважды, то оплата пройдёт два раза 😞

Это проблема. Если соединение оборвалось, клиент повторяет запрос и получает нежелательный дубликат. Но есть решение:
🔑 Используйте idempotency key (ключ идемпотентности).

Как это работает?

1️⃣ Генерируется ключ и передаётся в запросе:
– Клиент может сам создать ключ и передать его в заголовке.
– Либо сервер возвращает ключ при открытии формы, и фронт шлёт именно его.

2️⃣ Сервер проверяет ключ в запросе:
– Если запрос с таким ключом уже был, сервер не создаёт новую запись, а возвращает сохранённый результат первого запроса.
– Если ключ новый — выполняет действие и сохраняет результат вместе с этим ключом.

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

#api #rest #interview

Разбираем ответы

❌ /comments?articleId=42
Технически — корректно. comments выступает корневой коллекцией, а ?articleId=42 работает как фильтр. Однако по REST рекомендуется показывать вложенность прямо в пути, чтобы сразу было видно, к чему комментарии принадлежат. Они не живут сами по себе, а относятся к конкретной статье.

❌ /articles/comments/42
Нарушен порядок. Здесь непонятно, что такое comments/42. Это все комментарии статьи 42 или комментарий 42? URL двусмыслен 😞.

❌ /articles/42?comments
Параметр comments без значения, он ничего не уточняет. Если указываете параметр, то пишите, чему он должен быть равен. И помним, query-параметры используем в основном для фильтрации, сортировки, но не для получения вложенного ресурса.

❌ /comments/42/articles
Инвертирована иерархия. Тут выглядит так, будто у комментария 42 есть статьи. Логически неверно. У нас у статьи 42 есть комментарии.

✅ Правильный ответ
/articles/42/comments
Сначала ресурс «статья» (/articles/42), а внутри него подресурс comments. Так мы получим комментарии к конкретной статье.

#rest #api

Привет! 👋
С вами Вера, основатель AnalystCore.

REST, API, методы… Всё это, конечно, важно. Но есть тема, которую системные аналитики будто бы знают, но на практике оказывается, всё гораздо сложнее. Это требования.

Давайте сделаем паузу в теме REST и вернёмся к самому началу.
Потому что всё начинается именно с требований. Без них — всё остальное теряет смысл.

💬 Требования — это то, с чего начинается любая задача системного аналитика.
Но, если честно, эту тему часто недооценивают.
Кажется, ну что там сложного? Спросил, записал — готово.
А на деле:
📌 Требования бывают противоречивыми.
📌 Их нельзя просто «записать» — их нужно вытаскивать, распутывать, уточнять.
📌 То, как вы проработаете требования, влияет на всю реализацию задачи.
📌 Часто именно «плохие требования» становятся причиной багов и переделок.
И самое интересное — чем дольше вы работаете аналитиком, тем больше понимаете, сколько всего ещё не знаете про требования 😅

📆 В ближайшие недели будем вместе разбирать:
— кейсы, в которых не всё так однозначно,
— полезная теория и техники,
— лайфхаки и шпаргалки,
— подводные камни, с которыми вы сами могли не раз сталкиваться.

Оставайтесь с нами — будет интересно 😉

#requirements

Задача❓ Добавить новое обязательное поле «Цель кредита» в форму заявки на кредит.

💬 Бизнес говорит:

Нужно добавить поле «Цель кредита» в заявку. Это важно для отчётности. Сделайте обязательно для заполнения. Значения — стандартные.

Кажется, всё понятно. Но давайте подумаем — действительно ли тут всё так просто?

❓Вопрос к вам:
Как бы вы подошли к этой задаче как системный аналитик?
Над чем бы задумались? Что уточнили бы у заказчика, команды или у себя самого?

✍️ Напишите свои мысли в комментариях.
А в следующем посте мы поделимся своей версией.

Не пропустите.

#requirements

Задача❓ Добавить новое обязательное поле «Цель кредита» в форму заявки на кредит.

💬 Исходный запрос от заказчика:

Нужно добавить поле «Цель кредита» в заявку. Это важно для отчётности. Сделайте обязательно для заполнения. Значения — стандартные.

Что уточнить у заказчика, у команды и у самого себя?

1️⃣ Где именно размещаем?
В каком разделе формы?
До или после каких полей?
От этого зависит и UX, и порядок полей в отчёте и пр.

2️⃣ Обязательное — всегда?
Например, если пользователь сохраняет черновик — можно ли сохранить без этого поля?
Или только при финальной отправке заявки?
От этого зависит логика на фронте и бэке, валидация.

3️⃣ Что за «стандартные значения»?
Нужен чёткий справочник:
- Покупка авто
- Ремонт
- Путешествие
- Лечение
- Образование
- Иное (а если выбрали — показывать поле для уточнения?)
❗ А кто владелец справочника? Кто будет поддерживать его актуальность? Если завтра придёт бизнес с новой целью — кто её добавит и в каком виде?

4️⃣ А что делать со старыми заявками?
В старых заявках цели не было, а новое поле будет обязательным, что там проставлять?
Что проставлять в заявках со статусами «Черновик», «В работе» и пр.?

Будем делать маппинг на основе других полей? Возможно, можно подтянуть цель из комментариев, связанных документов, категорий заявки. Будем ли на это тратить силы? Завести ли отдельную задачу на это?

5️⃣ Где должно появиться поле?
В карточке заявки (в вебе и мобильном приложении)
В интерфейсе сотрудников
В отчётах и BI-системах
В БД, API

6️⃣ Как будет использоваться?
Влияет ли цель кредита на автоматическое решение?
Используется ли в отчётах?
Может ли повлиять на ставку / условия?

7️⃣ Есть ли ограничения?
Можно ли выбрать несколько целей?
Валидация для поля «Иное»?

А ещё смотрите классные вопросы, которые написали в комментариях под прошлым постом 👆.

📌 Как видите, даже простая задача может тянуть за собой десятки вопросов, решений и проработок.

В следующем посте расскажем, что ждут от системного аналитика в такой задаче: что он должен передать фронту, бэку, тестировщикам и менеджеру.
Не пропустите 😉

#requirements

📌 Что ждут от системного аналитика в ТЗ на добавление нового поля?

В прошлом посте мы разобрали, какие вопросы стоит задать, прежде чем добавлять новое поле «Цель кредита».
А теперь переходим к тому, что конкретно должен отдать аналитик своей команде.

💡 Сохраняйте, это пригодится в работе💡

🔷 Описание справочника
– Название: Цели кредита
– Список значений
– Указан владелец справочника (кто поддерживает актуальность)

🔷 Описание нового элемента UI
Обычно все элементы интерфейса описываются в виде таблицы. В неё нужно добавить новое поле. Продумайте:
– Где должно быть размещено поле
– В каких случаях оно обязательно
– Укажите возможные значения
– Есть ли значение по умолчанию
– Для цели «Иное» должно отображаться поле ввода «Иное» — описываем условия отображения
– Описываем валидацию для «Иное»: длина, допустимые символы, плейсхолдер и пр.
– Возможные ошибки и условия, когда они появляются
* Не забудьте добавить поле во все экраны, где оно появится. Например, есть ещё система для сотрудников банка, где они тоже могут заполнять и смотреть заявку.

🔷 Макеты
– Отрисуйте макеты сами или вместе с дизайнером
– Не забывайте про адаптивную версию: как поле будет отображаться на телефоне и планшете?
– Как поле выглядит в режиме редактирования и в режиме просмотра?
– Сценарии ошибок, плейсхолдеры, тексты валидаций
– Нужны ли подсказки к полю? (i)

🔷 Спецификация API
– Описание эндпоинта на получение справочника по шаблону (URL, алгоритм работы метода, входные параметры, выходные параметры, коды ответа)
– Добавьте новое поле во все методы, связанные с заявкой: на создание заявки, редактирование, получение
– Опишите новый параметр запроса по шаблону (название параметра, тип данных, обязательность, описание с учетом валидации)
– Опишите специфичную бизнес-логику, если она есть

🔷 Опишите сценарии взаимодействия
– В какой момент фронт будет запрашивать справочник?
– Что делать на фронте, если справочник не удалось получить (вернулась ошибка)?
– Кешируем ли справочник на фронте? На сколько?
– Если описываете, какие методы вызывает фронт и с какими параметрами, то обязательно уточните, как используется новое поле в запросах и ответах.

🔷 Изменения в БД
Как правило, все поля БД описываются в виде таблицы. В эту таблицу нужно внести новое поле:
– Найдите таблицу, куда добавите новое поле
– Название поля
– Тип данных
– Обязательность
– Описание (с учетом валидации)

🔷 Доработка сервиса принятия решений (если цель влияет)
– Влияет ли цель на ставку, срок, решение?
– Какие значения влияют и как?
– Обновите описание скоринга
– Кто согласует изменения логики?

🔷 Задача на миграцию. Обработка старых заявок
– Что делать с уже созданными заявками без цели?
– Какие значения подставлять?
– Если делаем маппинг — по каким правилам?
– Можно выгрузить заявки, вручную проставить цели в Excel и передать разработчику — он напишет миграцию
– Укажите, что миграция отображается в истории изменений от имени системного пользователя

🔷 Изменения для отчётности / BI
– В какие отчёты и выгрузки нужно добавить поле
– В каком месте появится новое поле
– Опишите поле
– Опишите цели использования поля

🔷 Для менеджера и всей команды
Напишите:
– Открытые вопросы и риски
– Что можно вынести вне MVP
– Места, где потребуется отдельное согласование и кого именно

💡 Как видите, простая задача оказалась не такой простой. B работе системного аналитика так всегда. Но вы и сами наверняка с этим сталкивались 🙂.


Если разбор понравился, ставьте реакции ❤️‍🔥, так мы узнаем, интересно ли это вам.

#requirements #тз_разбор

🎥 Посмотрите на курс изнутри!
Мы заглянули в первые модули, показали структуру и кусочек ДЗ.

👉 https://analystcore.com/system-analyst-base

Хотите сменить работу в этом году? 🎯

Если планируете переход — сейчас самое время начинать поиски и подготовку к собеседованиям.
В крупных компаниях часто есть годовые бонусы. Чтобы их получить, нужно отработать хотя бы полгода. А значит: устроиться до конца июня! 💸

📆 До лета — всего полтора месяца. Пора освежить знания и подготовиться к интервью.
Вот полезная подборка постов, которые помогут:

📌 Мой чеклист перед собеседованиями — это список тем, которые я всегда повторяю 😉
📌 Что происходит после нажатия на кнопку «Войти»?
📌 Задача на сбор требований и проектирование
📌 Задачи на определение «это синхронное или асинхронное взаимодействие?»
📌 Спроектируйте взаимодействие: выберите синхронный или асинхронный способ
📌 Задача на Use Cases
📌 Виды интеграций
📌 Безопасный и идемпотентный
📌 Как сделать POST-запрос идемпотентным?
📌 Почитайте все по хэштегу #api

И будьте готовы к личным вопросам:
– Расскажите о себе
– Как относитесь к переработкам?
– Что будете делать, если задача на 3 дня, а работы на 5?
– А если коллега вам не отвечает три дня, а он вам нужен — как поступите?

Если хотите не просто повторить, а наконец разобраться во всём системно, приходите на курс «Системный аналитик. БАЗА». Он поможет вам разложить знания по полочкам, чтобы пройти собеседование без страха и потом уверенно работать на новом месте.

🎯 Зачем выделять MVP даже в маленькой задаче?

Иногда кажется, что MVP — это для стартапов, больших релизов, глобальных фичей.
Но на деле его стоит выделять даже в небольших задачах. Вот пример 👇

💬 Задача
«Добавить возможность пользователю загружать документы по заявке»

Звучит просто. Но как только начинаем прорабатывать требование всплывают детали:

— А можно загружать сразу несколько файлов? Сколько максимум? Как они будут отображаться вместе на странице?
— А какие форматы и ограничения по размеру?
— Нужно ли разделять ошибки? Какие?
— Где пользователь потом увидит загруженные документы?
— Нужно ли, чтобы в списке заявок была иконка вложения, чтобы пользователь знал, в каких есть файлы, а в каких нет?
— А если пользователь случайно загрузил не тот файл? Как удалить?
— Делаем предпросмотр?
— Показываем прогресс‑бар загрузки?
и пр.

📌 И вот уже «простая» задача превращается в мини‑проект с UX-сценариями, вопросами по API, фронту, бэку и дизайну.
И всё «надо, желательно, хотелось бы». И всё это увеличивает срок разработки и тестирования.

✅ Именно в этот момент аналитик должен остановиться и совместно с командой выделить MVP — минимальный объём, чтобы пользователь мог загрузить файл и отправить заявку.

В итоге MVP:
— Грузим только один файл (представим, что для нашего кейса — это ок)
— Только PDF, до 5 МБ (если нужно загрузить несколько скриншотов — пусть объединят в один PDF)
— Без предпросмотра, разделения ошибок, прогресс‑бара, иконки вложения, без удаления (пусть если что новую заявку создают) и пр.

Остальное добавляем в бэклог, отдельными задачами. Выкатим в следующих релизах.

💡 Плюсы:
— задача ушла в разработку на следующий день;
— сделали быстро;
— релиз не сорвался;
— пользователь смог загрузить документ — миссия выполнена ✅

Выделять MVP можно и нужно не только для больших задач.
Даже в маленькой задаче это спасает от переработок, задержек и метаний «а давайте добавим ещё…». Когда ограничены сроки, ваше спасение — выделить MVP.

#requirements