Идемпотентность и мидлвары
Сеть несовершенна: клиент «не получил ответ» и повторяет запрос. Если сервер списал деньги второй раз — виновата не сеть, а дизайн API. Идемпотентность это лечит.
Правила идемпотентности
- повторный
GETиDELETE— безопасны по своей природе; PUT— заменить объект тем же состоянием, повтор не даёт разницы;- платежи/создание — спец-ключ
Idempotency-Key
app.post("/payments", async (req, res) => {
const key = req.headers["idempotency-key"];
const done = await redis.get(`pay:${key}`);
if (done) return res.json(done); // уже обрабатывали
const result = await charge(req.body);
await redis.set(`pay:${key}`, JSON.stringify(result), "EX", 3600);
res.json(result);
});
Мидлвары — конвейер перед логикой
app.use(logRequests); // логи
app.use(parsers.json()); // тело
app.use(authMiddleware); // проверка токена → req.user
app.post("/orders", createOrder); // обработчик уже «чистый»
💡
Держите обработчики тонкими, средние слои — общими: лог-ауты, auth, лимиты (урок 80), валидация. Порядок мидлвар = порядок гарантий перед бизнес-логикой.
ℹ️
Webhook провайдеров (урок 72, 89) дублирует события «на всякий случай»: без идемпотентности ваш инвойс посчитается дважды. Идемпотентность на бэке — базовая практика, а не хардкор.