💳 Подвійне списання грошей: Що таке Ідемпотентність API і як її тестувати

Привіт, екіпаж! Сьогодні розберемо один із найдорожчих багів електронної комерції та страшне слово, яким бекендери люблять лякати джунів. ☕️Уявіть класичну ситуацію:

Ви купуєте квитки на поїзд. Вводите дані картки, тиснете "Оплатити". Інтернет на секунду "зависає". Лоадер не крутиться. Ви нервуєте і тиснете кнопку "Оплатити" ще тричі. Нарешті з'являється екран успіху. Ви заходите в банкінг і бачите, що гроші списалися чотири рази. Ви купили 4 однакові квитки на одне й те саме місце.Чому це сталося?

Тому що розробник забув про Ідемпотентність (Idempotency).Що це за звір?

В IT ідемпотентність — це властивість системи, при якій багаторазове повторення однієї і тієї ж дії дає той самий результат, що й одноразове.
🔹

Метод GET — ідемпотентний. Скільки б разів ви не запитували баланс, баланс не зміниться від самого запиту.🔹

Метод DELETE — ідемпотентний. Якщо ви видалили юзера номер 5, повторний запит на видалення просто скаже "Його вже немає", а не видалить когось іншого.🔹

А от метод POST (створення замовлення, оплата) — НЕ ідемпотентний за замовчуванням. Кожен новий запит POST створює новий об'єкт.
Як архітектори захищають систему?

Щоб 4 кліки не перетворилися на 4 оплати, фронтенд при натисканні кнопки генерує унікальний рядок — Idempotency-Key (Ключ ідемпотентності) — і відправляє його в заголовках (Headers) запиту. Бекенд бачить ключ, проводить оплату і "запам'ятовує" його. Якщо через секунду прилітає ще один запит із таким самим ключем, бекенд розуміє: "Ага, це дубль від нервового юзера або лаг мережі". Він не знімає гроші вдруге, а просто повертає ту саму відповідь, що й першого разу.Як QA має це тестувати? (Краш-тест оплати)

Не довіряйте UI, блокування кнопки "Pay" після першого кліку — це захист від "дурня", а не надійна архітектура.⚡️ Тест дубля через Postman

Створіть запит на покупку товару. Скопіюйте його. Відправте запит. А потім відразу відправте його ще раз, не змінюючи жодного символу (і не міняючи Idempotency-Key, якщо він є). Очікуваний результат: Другий запит НЕ повинен створити нове замовлення. Він має повернути або помилку 409 Conflict, або статус 200 OK (але ID замовлення у відповіді має бути від першої транзакції!).

🐢 Тест "Поганого інтернету"
Відкрийте Chrome DevTools -> Network -> Throttling -> увімкніть Slow 3G. Заповніть форму, натисніть "Надіслати" і почніть швидко клікати по кнопці ще 10 разів, поки запит "висить" у повітрі. Якщо в базі з'явилося 10 однакових записів — заводьте Blocker.
Висновок: Ідемпотентність — це бронежилет вашого бізнесу. Якщо ви тестуєте фінтех, е-коммерс або бронювання — це перше, що ви маєте перевірити на API рівні.А ви стикалися з подвійним створенням сутностей на своїх проєктах?

👇🔥 — О так, постійно ловимо баги з подвійними кліками!

👀 — У нас кнопка просто блокується, сподіваємось, цього достатньо...

🤯 — Прямо зараз піду перевіряти нашу адмінку через Postman!