Что такое идемпотентность в программировании?

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

Если по-простому, на пальцах: Ты сделал что-то один раз — получил результат. Сделал это же самое ещё десять раз — результат должен быть точно таким же, как будто ты сделал это только один раз. Не создалось десять одинаковых заказов, не списалось десять раз деньги. Вот и вся магия.

Вот смотри, как это в HTTP методах выглядит:

А теперь, блядь, самый сок — как это в коде делать. Вот тебе пример на C#, смотри:

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    [HttpPut("{id}")]
    public async Task<IActionResult> UpdateOrder(Guid id, UpdateOrderRequest request)
    {
        // Сначала ищем заказ, который хотим обновить
        var order = await _repository.GetByIdAsync(id);
        if (order == null)
            return NotFound(); // Не нашли — и ладно, результат фиксированный

        // Вот тут фишка! Проверяем версию, чтобы не перезаписать чужие изменения
        if (order.Version != request.ExpectedVersion)
            return Conflict("Заказ уже кто-то успел поменять, пока ты думал!"); // Конфликт — тоже предсказуемый результат

        // Обновляем и увеличиваем версию
        order.Update(request);
        order.Version++;

        await _repository.UpdateAsync(order);
        return Ok(order); // И всегда возвращаем один и тот же ответ для одних и тех же данных
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteOrder(Guid id)
    {
        // Классика идемпотентности! Удалил заказ — ок. Пытаешься удалить несуществующий — тоже ок, ведь цель (чтобы его не было) достигнута.
        var order = await _repository.GetByIdAsync(id);
        if (order == null)
            return NoContent(); // Или Ok() — главное, поведение одинаковое!

        await _repository.DeleteAsync(id);
        return NoContent();
    }
}

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

public class PaymentService
{
    public async Task<PaymentResult> ProcessPayment(PaymentRequest request)
    {
        // 1. Секретный ключ! Клиент присылает уникальный ключ идемпотентности (IdempotencyKey) с каждым запросом.
        // Ищем, не обрабатывали ли мы уже платеж с таким ключом.
        var existingPayment = await _repository.GetByTransactionId(request.IdempotencyKey);
        if (existingPayment != null)
        {
            // Опа! Уже обрабатывали. Возвращаем сохранённый результат, а не идём в банк снова.
            return new PaymentResult { Success = true, TransactionId = existingPayment.Id };
        }

        // 2. Если не обрабатывали — создаём запись "в процессе" и идём в банк.
        var payment = new Payment(request);
        await _repository.AddAsync(payment);

        // ... тут вызов банковского шлюза ...

        // 3. Результат (успех или провал) навсегда привязываем к этому IdempotencyKey.
        payment.MarkAsCompleted(gatewayResult.TransactionId);
        await _repository.UpdateAsync(payment);

        return new PaymentResult { Success = true, TransactionId = payment.Id };
    }
}

Какие ещё есть приёмчики, чтобы не облажаться?

1. Ключ идемпотентности (Idempotency Key). Это как номер чека. Пришёл с одним и тем же номером — получи тот же самый чек, а не новый товар.
2. Оптимистичная блокировка. Используешь поле Version в базе, как в примере выше. Если версия не совпала — значит, кто-то другой уже всё поменял, твоё действие устарело.
3. Проверка состояния. Перед тем как что-то делать, смотришь: «А не сделано ли это уже?». Если заказ уже оплачен — просто возвращаем «Ок, оплачено», а не пытаемся оплатить снова.
4. Саги с компенсациями. Для совсем уж сложных, неидемпотентных операций. Сделал первый шаг — запомни, как его откатить, если что. Это как купил пива, а потом понял, что денег нет — идешь возвращать.

И главное, запомни разницу:

• Идемпотентность — про результат. Сделал много раз = результат как от одного раза.
• Безопасность (Safety) — про то, меняешь ли ты что-то вообще. GET — безопасный (только читает). PUT — идемпотентный, но не безопасный (он меняет данные, просто делает это предсказуемо).

Короче, проектируя любое API, которое хоть что-то меняет, сразу думай: «А что будет, если этот запрос прилетит ко мне два раза?». Если ответ тебя пугает — значит, пора встраивать идемпотентность, пока пользователи не начали звонить с матами.