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

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

Кейс 1️⃣. Удаление банковской транзакции

Вы совершили отложенный перевод денежных средств в банк клиенте. Заявка в статусе на отправку, но деньги еще не ушли и вы хотите ее удалить.

Что делать?

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

➡️ можно сделать SOFT DELETE и просто прокинуть статус disable, а лучше поменять статус на "отменена" и тогда сохранится историчность.

Кейс 2️⃣. Удаление товара из системы в интернет-магазине.

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

У вас есть старые товары, которые уже перестали продаваться в магазине. Сотрудник хочет их удалить.

Что делать?

Тут у нас двоякая ситуация, потому что с одной стороны, товар уже не используется, но не факт что он не использовался раньше, и отсутствует в заказах, поэтому здесь можно пойти таким путем:

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

➡️ Если был, то удалять такой товар нельзя и его нужно архивировать, так как, если мы его удалим, у нас умрут связи и это повлияет не только на историю заказов, но может затронуть финансовые операции, расчеты, а это очень больно, уж поверьте. Используем SOFT DELETE.

➡️ Если товар ни с чем не связан, то спокойно делаем DELETE.

Кейс 3️⃣. Удаление учётной записи пользователя в интернет-магазине

У вас есть учетная запись и функциональность по удалению этой учетки. Как ее реализовать?

Тут как и в предыдущем пункте - два варианта:

➡️ Если у пользователя не было покупок → можно удалить его аккаунт так:

DELETE /users/{id}

➡️ Если он совершал заказы → удалять нельзя, потому что его данные связаны с чеками, гарантиями, возвратами, заказами.

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

➡️ во всех случаях, когда Клиент удаляет учетку, я бы делал SOFT DELETE и еще добавил бы анонимность данных.

➖➖➖

А дальше дело техники

Как оформить запрос при DELETE и SOFT DELETE?

«Полное» удаление (DELETE)

• Метод: DELETE

• Endpoint: /resource/{id}

«Мягкое» удаление (SOFT DELETE)

• Метод: чаще PATCH или PUT

• Endpoint: resource/{id}, где передаём значение поля is_deleted = true или archived = true или status = "cancelled".

Пример:

PATCH /api/v1/products/123

Headers:
Content-Type: application/json

Body:
{
"is_archived": true,
"archived_at": "2025-02-26T12:00:00Z"
}

Почему при SOFT DELETE мы не используем метод DELETE?

В целом, мы можем делать и soft delete и обычное удаление через метод DELETE, но в этом случае такой запрос не очевидно читается. И внутри придется делать дополнительную логику.

⚡️⚡️⚡️

Не важно через какой метод вы это делаете, важно лишь то, что вы понимаете БАЗОВЫЕ принципы и  логику, а еще используете мышление системного аналитика для решения таких задач.

У нас есть трекер калорий и него есть классная фича- сканирование штрих-кода для автозаполнения КБЖУ.

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

Тебе поставили задачу - описать требования к UI. 

И один из способов это сделать –  использовать USE CASES

Классически USE CASE выглядит так:

✔️ Название,

✔️ Актёры,

✔️ Предусловия,

✔️ Основной сценарий,

✔️ Альтернативные/ошибочные потоки,

✔️ Результат.

Теперь применяем это к нашему примеру:

✔️ Название:

UC‑1 Быстрое добавление продукта по штрих‑коду

✔️ Основной актёр:

Пользователь приложения

Системы:

Мобильное приложение, Back-сервис.

✔️ Предусловия:

- Приложение получило разрешение на доступ к камере.

- Устройство подключено к интернету.

✔️ Основной сценарий:

1. Пользователь открывает экран «Добавить продукт» и нажимает «Сканер штрих‑кода»;

2. Камера считывает шрих-код и отправляет POST /barcode/scan {code} на Backend;

3. Backend ищет у себя в кэше.

- Если найден, возвращает нутриенты и калории.

- Если не найден, то идет во внешних API.

4. API отвечает 200 OK, Backend нормализует данные, рассчитывает калории по формуле, кладёт результат в кэш.

5. Приложение показывает карточку продукта с БЖУ и кнопкой «Добавить в дневник».

✔️ Альтернативы:

2А. Камера не запустилась — приложение предлагает ввести код вручную;

3А. Внешний API вернул 404 — открывается форма ручного ввода нутриентов;

3B. API отвалилась по таймауту — показывается заглушка «Сервис недоступен», предлагается сфотографировать этикетку;

✔️ Постусловия:

- При успешном сценарии - продукт сохранён в дневнике, данные кэшированы;

- При ошибках пользователь получил понятный способ продолжить.

➖➖➖

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

➖➖➖

Но что в этом подходе не так? 

❗️А то, что front разработчику вообще не нужно знать, что происходит на стороне back, а back разработчику может и важно, что там делает фронт, но скорее нет = ИЗБЫТОЧНОСТЬ, которая и порождает за собой лишние вопросы со стороны команды. 

➖➖➖

Так что же важно, когда мы описываем UI?

❗️Я в своей практике использую такой подход: разбиваю USE CASE на шаги и расписываю отдельно действия пользователя, и отдельно - системы, в рамках одного шага. 

Вернемся к нашему примеру,

✔️ Название:

UC‑1 Быстрое добавление продукта по штрих‑коду

Шаг 1: Сканирование штрих-кода

Действие пользователя: 

- Пользователь находится на экране добавления продукта;

- Пользователь нажал кнопку «Сканировать штрих-код».

Действие системы:

1. Система считывает штрих‑код и отправляет запрос:

Request: POST /barcode/scan {code} на Backend.

Response: JSON

- если данные получены, то перейти к шагу: отображение карточки продукта с БЖУ;

- если данные не пришли, то перейти к шагу: ввод данных вручную.

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

➖➖➖

Почему самообучение — не всегда выход? 

Когда ты ищешь информацию в инете, то часто она уровня "обыватель".

В итоге:

✖️ неясно, что действительно нужно учить, а что — пустая трата времени;

✖️ нет обратной связи — ты не понимаешь, правильно ли всё усвоил;

✖️ нет структуры и целостного понимания.

Что даёт мой курс? 

✔️ БАЗУ, которая нужна и для работы, и техсобесов,

✔️ Много практики,

✔️ Подробные комментарии к домашкам,

✔️ И главное — мой личный опыт и подходы, которые превращают тебя не просто в аналитика, а в незаменимого специалиста, которого ценит команда

ПОДПИСЫВАЙСЯ НА МОИ СОЦ СЕТИ:

ИНСТА | ТЕЛЕГРАМ | YOUTUBE | VK

Курс только начался, а у ребят уже есть вопросы на эту тему и я хочу поделится ответом и с вами тоже.

Кто-то думает, что это защита шифрование SSL, но нет это не так.

✔️ Это encoding — это когда твоя строка превращается в безопасный формат для URL.

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

Самый частый пример, где мы можем встретить encoding, это в поисковиках. Попробуйте вбить в Google слово матрешка и посмотрите в консоль разработчика.

Там вы увидите вместо нормального слова - это

https://www.google.com/search?q=%D0%BC%D0%B0%D1%82%D1%80%D0%B5%D1%88%D0%BA%D0%B0

Еще, понимание, что это такое, может нам пригодится при разборе логов, потому что запрос прилетит именно в таком виде.

➖➖➖

Но, как понять, что закодировано в сообщении, если мы не знаем изначальный запрос?

✔️ Нам нужно сделать decoding – обратное превращение закодированной строки в обычную.

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

Самый сложный вариант - это найти таблицу UTF-8 и посмотреть, что значит конкретный символ.

Например, буква М будет выглядеть так %D0%BC

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

Сервисов много.

💾 Например, https://www.urldecoder.org/ru

✔️ переходим по ссылке,

✔️ вбиваем наши кракозябры,

✔️ нажимаем декодировать

🪄 вуаля, у вас нормальная строка

Го декодировать заголовок  🥂

ПОДПИСЫВАЙСЯ НА МОИ СОЦ СЕТИ:

ИНСТА | ТЕЛЕГРАМ | YOUTUBE | VK