💳 Подвійне списання грошей: Що таке Ідемпотентність 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!