Всім привіт! Сьогодні принесла Вам дуже цікаву вижимку з традиційного вівторкового вебінару! А говорили ми про те, про що не говорять 😁Дивимось 👇🏻 👩🏼‍💻 Інна Осінна: «Ідемпотентність. Речі, про які не говорять»🪄 Ідемпотентність: N запитів -> 1 результат (один запис у БД).❌ Ідемпотентність - це не однакова відповідь на кожен запит, не однаковий статус код, відсутність побічних ефектів.✅ GET, HEAD, OPTIONS - ідемпотентні та safe (ті які нічого не змінюють у БД). ☑️ PUT, DELETE - ідемпотентні - бо вони всього лиш перезаписують існуючий запис, а не створюють його. ❔ PATCH - залежить від реалізації. ❌ POST - не ідемпотентний, бо створює кожен раз новий ресурс. І тут проблема: Бо ми маємо розрізняти retry і single request за допомогою Idempotency key. 📖 IETF RFC 9110. 🧗 5 рівнів перевірки: • Response • Database • Message queue • Email service • Webhook logs💪🏼 Топ помили при реалізації: • Зберігаємо лише ключ, а не відповідь. • Немає валідації body для одного ключа. • Race condition при запису ключа. • Side effect поза транзакцією. • Сховище без TTL або занадто короткий. • DELETE віддає різні коди при повторі. • POST без idempotensy key. Також ми мали дуже класну демку на прикладі Stripe з використанням різних скриптів, тулів і тд. 🔥Вебінар був дуже цікавий! Бо особисто я про ідемпотентність почула вперше (і востаннє) на курсі Інни 😁 Але вже зараз, почала помічати, що про це дізнається більша кількість людей і навіть стараються питати на співбесідах) Коли я востаннє шукала роботу, то мене про це спитали двічі (все ще мало, але хоча б хтось). ❔А Вас коли-небудь питали про ідемпотентність на співбесіді? 👍🏼 - так. 👎🏼 - ні. 👌🏼 - дуже рідко питають. 🌚 - сам (-а) вперше про це чую.