Webhook nima: tizim oʻzi xabar beradi, siz soʻramaysiz

Stripe hujjati webhook kerak boʻladigan uchta holatni sanaydi: mijozning banki toʻlovni tasdiqladi, mijoz toʻlovni bahslashdi, takroriy toʻlov muvaffaqiyatli oʻtdi. Uchalasida ham voqea sizning soʻrovingizdan keyin, sizdan mustaqil ravishda sodir boʻladi. Savol oddiy: bu haqda qanday bilib olasiz?

Ikki yoʻl: har daqiqa soʻrash yoki xabar kutish

Birinchi yoʻl — polling: dasturingiz boshqa tizimning API ga muntazam murojaat qilib, yangilik bormi, deb soʻraydi. Zapier lugʻatida trigger shunday taʼriflanadi: yangi maʼlumot yo API oxirgi nuqtasini soʻrab turish orqali, yo ilovaning webhook xabari orqali aniqlanadi.

Ikkinchi yoʻl — webhook. Voqea yuz berganda manba tizim oʻzi sizning manzilingizga HTTP soʻrov yuboradi. GitHub buni shunday taʼriflaydi: maʼlum voqealar yuz berganda xabarlar tashqi veb-serverga yetkaziladi, bu API ni soʻrab turishning aksi. Vikipediyada atama qisqaroq berilgan: foydalanuvchi belgilagan HTTP chaqiruvlari.

Farqni oddiy hisob koʻrsatadi. Bu taxminiy misol: agar buyurtma holatini har besh daqiqada soʻrasangiz, sutkada 288 ta soʻrov yuborasiz. Voqea kuniga uch marta yuz bersa, qolgan 285 ta soʻrov boʻsh javob oladi. Yangilik esa oʻrtacha bir necha daqiqa kechikib bilinadi. Webhookda soʻrov faqat voqea boʻlganda keladi. Odoo hujjati ham shu farqni taʼkidlaydi: webhook rejalashtirilgan harakatlardan farqli ravishda real vaqtdagi, hodisaga asoslangan aloqani beradi.

Evaziga qabul qiluvchi tomonda ochiq manzil kerak. Stripe roʻyxatdan oʻtkaziladigan manzil ommaga ochiq HTTPS URL boʻlishini talab qiladi. Oʻz kompyuteringizda ishlab chiqilayotgan dastur uchun hujjat ngrok kabi tunnel vositasini yoki Stripe CLI ni taklif qiladi.

Polling ham oʻz oʻrnini yoʻqotmagan. GitHub hujjati ruxsat beradi: maʼlumot bir marta yoki vaqti-vaqti bilan kerak boʻlsa, resurslar soni kam boʻlsa va kengaytirish rejasi yoʻq boʻlsa, REST API ga kerak paytida murojaat qilish kifoya. Webhook doimiy kuzatuvni talab qiladigan, voqea soni katta va kechikish qimmat turadigan joyda oʻzini oqlaydi. Tanlov texnologiyaning yangiligiga emas, voqea qanchalik tez-tez va qanchalik shoshilinch boʻlishiga bogʻliq.

Atama qayerdan kelgan

Atama dasturchi Jeff Lindsay bilan bogʻlanadi: Mozilla yozuvida u webhook atamasini kiritgan va bu yoʻnalishda yoʻl ochgan shaxs sifatida tilga olinadi. Aniq yil boʻyicha manbalar kelishmaydi. Vikipediya 2007 yilni koʻrsatadi. Simon Willison esa 2009 yil fevralida Lindsayning «Web Hooks and the Programmable World of Tomorrow» maʼruzasini oʻz blogida keltirib, uni «tour de force» deb baholagan. Uning asosiy fikri amaliy: Flickr darajasidagi yirik xizmat boʻlmasa, webhookni kam xarajat bilan joriy qilish mumkin, bu esa foydalanuvchilarda ijodkorlik toʻlqinini uygʻotadi.

Xabar qanday koʻrinadi

Stripe webhook xabarini HTTPS orqali JSON yuklama sifatida yuboradi. Qabul qiluvchi funksiya POST soʻrovini qabul qilib, 2xx kodli javob qaytarishi kerak. n8n kabi avtomatlashtirish vositasida bu «Webhook» tuguni: u ish jarayonini boshlaydi, sinov va ishchi manzillari alohida beriladi, yuklamaning eng katta hajmi 16 MB. Javob rejimi ham tanlanadi: «darhol» rejimida tugun 200 kodi va «Workflow got started» xabarini qaytaradi, «oxirgi tugun tugaganda» rejimida esa butun zanjir tugaguncha javob kutiladi. Yuboruvchi taymauti qisqa boʻlsa, ikkinchi rejim xavfli.

Odoo 20 da webhook Studio ichida sozlanadi. Tashqi tizim yuklamani Odoo webhook manziliga POST soʻrovi bilan yuboradi, Odoo esa oldindan belgilangan harakatni bajaradi. Hujjatda ikkita misol bor: buyurtma raqami kelganda uning valyutasini USD ga oʻzgartirish va yuklamadagi ism hamda email boʻyicha yangi kontakt yaratish. Sozlash boʻyicha ikki ogohlantirish bor. Manzil maxfiy: uni ochiq joyda ulashish bazaga kutilmagan kirishga yoʻl ochishi mumkin. Sinovni jonli bazada emas, uning nusxasida oʻtkazish kerak.

Nosozlikni topish uchun «Log Calls» parametrini yoqish mumkin: webhook manziliga kelgan soʻrovlar tarixi saqlanadi va «Logs» tugmasi orqali koʻriladi. Sinov paytida 200 OK javobi webhook Odoo tomonida ishlayotganini bildiradi; 500 esa Odoo yuklamani toʻgʻri oʻqiy olmaganini koʻrsatadi. Hujjat teskari yoʻnalishni ham eslatadi: Odoo ichidagi avtomatik harakat maʼlumot oʻzgarganda tashqi webhook manziliga xabar yuborishi mumkin.

Yaxshi qabul qiluvchi funksiya bir necha qisqa qadamdan iborat. Quyidagi tartib Stripe va GitHub tavsiyalarining umumlashmasi, aniq kod emas.

1. Soʻrov keladi; xom tana va sarlavhalar oʻzgartirilmay oʻqiladi.
2. Imzo va vaqt belgisi tekshiriladi; mos kelmasa — rad etiladi.
3. Voqea identifikatori yangimi, tekshiriladi; takror boʻlsa, hech narsa qilinmaydi.
4. Voqea navbatga qoʻyiladi va darhol 2xx javob qaytariladi.
5. Asosiy ish navbatdan, oʻz tezligida bajariladi.

Bu tartibda javob qaytarish ishni bajarishdan oldin turadi. Sabab shunda: ishning oʻzi sekin boʻlishi, tashqi tizimlarga tayanishi va yuklama oshganda toʻxtab qolishi mumkin.

Birinchi xavf: xabarni kim yubordi?

Webhook manzili internetga ochiq, demak unga istalgan kishi soʻrov yuborishi mumkin. Stripe buni ochiq yozadi: tekshiruvsiz tajovuzkor soxta voqea yuborib buyurtmani bajartirishi, hisobga kirish huquqini berishi yoki yozuvni oʻzgartirishi mumkin.

Standart himoya — imzo. Yuboruvchi va qabul qiluvchi umumiy maxfiy kalitni biladi. Yuboruvchi xabar tanasidan shu kalit bilan HMAC (hash va maxfiy kalitga asoslangan xabar autentifikatsiya kodi, RFC 2104) hisoblab, natijani sarlavhaga qoʻshadi. Qabul qiluvchi oʻzi ham hisoblab, solishtiradi. Mos kelmasa, xabar soxta yoki yoʻlda oʻzgargan.

GitHub imzoni X-Hub-Signature-256 sarlavhasida yuboradi: qiymat sha256= bilan boshlanadi, undan keyin xabar tanasining HMAC-SHA256 natijasi hex koʻrinishida keladi. Solishtirishni oddiy tenglik bilan emas, vaqtga bogʻliq boʻlmagan (constant-time) funksiya bilan bajarish kerak. Stripe sarlavhasi boshqacha: Stripe-Signature ichida vaqt belgisi (t=) va imzo (v1=) bor, imzolanadigan satr «vaqt, nuqta, xabar tanasi» tartibida tuziladi.

Ikkala provayder ham bir tuzoqni alohida taʼkidlaydi: imzo xabar tanasining aynan oʻsha baytlariga hisoblanadi. Stripe xom (raw) tanani framework oʻzgartirib yubormasligini talab qiladi. GitHub tanani yoki sarlavhani oʻzgartiradigan proksi va yuk taqsimlagich (load balancer) tekshiruvni buzishini qayd etadi.

Imzo toʻgʻri boʻlsa ham xabar eski boʻlishi mumkin: tajovuzkor ushlab olingan haqiqiy xabarni qayta yuborishi (replay hujumi) mumkin. Shu sababli Stripe vaqt belgisini imzo ichiga kiritadi, kutubxonalarida esa vaqt farqi uchun odatiy chegara 5 daqiqa. GitHub har yetkazib berishning noyob X-GitHub-Delivery sarlavhasidan foydalanishni tavsiya etadi.

Odoo ning shu sahifasida imzo sarlavhasi tasvirlanmagan. Himoya manzilning maxfiyligiga tayanadi, «Rotate Secret» tugmasi esa yangi manzil yaratadi. Amalda Odoo webhook manzili parol kabi saqlanadi: chatga, jamoaviy hujjatga yoki jurnalga tushmasligi kerak.

Har provayder oʻz sxemasini oʻylab topgani uchun qabul qiluvchi har safar yangi kod yozadi. Standard Webhooks tashabbusi buni birxillashtirishga urinadi: texnik qoʻmitada Zapier, Twilio, ngrok, Supabase, Svix, Kong kabi kompaniyalar vakillari bor. Spetsifikatsiya uchta sarlavhani belgilaydi: webhook-id, webhook-timestamp va webhook-signature; imzolanadigan satr «id.vaqt.tana» koʻrinishida tuziladi.

Ikkinchi xavf: javob berish va qayta yuborish

Webhook yuborayotgan tizim javobni kutadi, kech kelsa — xato deb hisoblaydi. GitHub 10 soniya ichida 2xx javob kutadi, aks holda ulanishni uzadi va yetkazishni muvaffaqiyatsiz deb belgilaydi. Stripe talabi sifat jihatidan shunday: murakkab ishdan oldin tezda 2xx qaytaring. Hujjatdagi misolda hisob tizimida hisob-fakturani «toʻlandi» deb belgilashdan oldin 200 javob qaytariladi. Yechim — xabarni navbatga qoʻyib, ishni keyin bajarish.

Keyingi savol: yetkazilmay qolsa nima boʻladi. Bu yerda ikki yirik provayder bir-biridan farq qiladi. Stripe jonli rejimda yetkazishni uch kungacha eksponensial kechikish bilan takrorlaydi, sinov rejimida bir necha soat ichida uch marta urinadi. GitHub muvaffaqiyatsiz yetkazishni avtomatik qayta yubormaydi: ularni API orqali topib, qoʻlda yoki skript bilan qayta yuborish kerak. Demak, qayta yuborish mantigʻi provayderga bogʻliq va uni taxmin qilib boʻlmaydi.

Standard Webhooks tavsiyasi ikkinchi tomonga yaqin: bir necha kunga choʻzilgan eksponensial kechikish va tasodifiy tebranish (jitter). Misol jadvalida oxirgi urinish taxminan 75,5 soatdan keyin, soʻrov taymauti 15–30 soniya. 410 Gone javobi yuboruvchiga manzilni oʻchirish signalini beradi. Taymaut ham hamma joyda bir xil emas: GitHub 10 soniya kutadi, Standard Webhooks esa 15–30 soniyani tavsiya etadi. Qabul qiluvchi dasturni eng qisqa taymautga moslash xavfsizroq.

Takror, tartibsizlik va yoʻqolgan xabar

Stripe uch narsani ochiq aytadi. Bir xil voqea ikki marta kelishi mumkin. Voqealar yaratilgan tartibda yetkazilishi taʼminlanmaydi. Ayrim hollarda ikkita alohida Event obyekti yuboriladi. Masalan, obuna yaratilganda customer.subscription.created, invoice.created va invoice.paid ixtiyoriy tartibda kelishi mumkin. Yechim ikki qismdan iborat: qayta ishlangan voqea identifikatorlarini saqlash va yetishmayotgan obyektni API dan oʻqib olish. Birinchi qism idempotentlik deb ataladi va alohida mavzu.

Hech bir qayta yuborish jadvali xabarning albatta yetib kelishini bildirmaydi. Natijasi nomaʼlum qolgan holatda Stripe API dan tegishli obyektni oʻqib, webhook voqealari bilan solishtirib holatni tiklashni tavsiya etadi. Hujjat yana bir narsani eslatadi: webhook handler API javobi orqali kelmagan obyektlarni ham qayta ishlashga tayyor boʻlishi kerak.

Bundan nima kelib chiqadi

Quyidagi savollar yuqoridagi hujjatlardan chiqarilgan tahririyat xulosasi. Webhook ulashdan oldin dasturchiga berish foydali:

1. Xabar haqiqiyligi qanday tekshiriladi: imzo bormi yoki faqat maxfiy manzilmi? Kalit qayerda saqlanadi va qachon almashtiriladi?
2. Qabul qiluvchi necha soniyada javob beradi va ogʻir ish navbatga oʻtkazilganmi?
3. Bizning tomon toʻrt soat ishlamay qolsa, yuboruvchi qancha vaqt takrorlaydi va undan keyin nima boʻladi?
4. Bir xil voqea ikki marta kelsa, ikkita hujjat yaratilmaydimi?
5. Xabar umuman kelmagan boʻlsa, buni qaysi jarayon topadi? Masalan, kuniga bir marta API orqali solishtirish bormi?

Oxirgi savol koʻpincha qoldiriladi. Webhook tezlik beradi, ammo Stripe ham, GitHub ham hujjatlarida yoʻqolgan xabarlarni keyinroq API orqali topishni nazarda tutadi. Amalda webhookni tezkor signal, API ni esa holatni tekshirish vositasi deb qarash xavfsizroq.