Stripe ຈື່ຄໍາຮ້ອງຂໍຂອງທ່ານເມື່ອຄໍາຕອບຫາຍໄປ

ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

• ຄວາມຄົງຕົວແມ່ນກ່ຽວຂ້ອງກັບຜົນກະທົບທີ່ຕັ້ງໃຈຂອງການເຮັດຊໍ້າຄືນການດໍາເນີນງານ. Stripe API v1 ເພີ່ມສັນຍາການຫຼິ້ນຄືນຄໍາຕອບທີ່ບັນທຶກໄວ້.
• ການລອງໃໝ່ຂອງການກະທໍາຢ່າງມີເຫດຜົນອັນດຽວກັນໃຊ້ກະແຈ ແລະ ພາລາມິເຕີອັນດຽວກັນ. ຮັກສາກະແຈການດໍາເນີນງານໄວ້ໃນການໂທ SDK ແຍກຕ່າງຫາກ ຫຼື ການເລີ່ມຕົ້ນແອັບພລິເຄຊັນໃໝ່; ການກະທໍາໃໝ່ຢ່າງແທ້ຈິງຕ້ອງການກະແຈຂອງມັນເອງ.
• ຫຼັງຈາກການປະຕິບັດຈຸດສິ້ນສຸດເລີ່ມຕົ້ນ, Stripe API v1 ຈະບັນທຶກສະຖານະ ແລະ ເນື້ອໃນຂອງຄໍາຮ້ອງຂໍທໍາອິດ, ລວມທັງຂໍ້ຜິດພາດ 500, ແລະ ສົ່ງຄືນຄໍາຕອບທີ່ບັນທຶກໄວ້ນັ້ນໃນການລອງໃໝ່.
• ພາລາມິເຕີທີ່ປ່ຽນແປງດ້ວຍກະແຈດຽວກັນເຮັດໃຫ້ເກີດຄວາມບໍ່ກົງກັນ. ຄວາມລົ້ມເຫຼວໃນການຢືນຢັນ ແລະ ຂໍ້ຂັດແຍ່ງການປະຕິບັດພ້ອມກັນບໍ່ບັນທຶກຜົນໄດ້ຮັບທີ່ຄົງຕົວສໍາລັບການພະຍາຍາມນັ້ນ ແລະ ສາມາດລອງໃໝ່ໄດ້.
• Stripe ຮັກສາກະແຈ API v1 ໄວ້ຢ່າງໜ້ອຍ 24 ຊົ່ວໂມງ ແລະ ສາມາດລຶບພວກມັນອອກໄດ້ຫຼັງຈາກນັ້ນ. ຈໍາກັດການລອງໃໝ່ເຄືອຂ່າຍທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂໄວ້ພາຍໃນ 24 ຊົ່ວໂມງທໍາອິດ, ຫຼັງຈາກນັ້ນຢຸດ ແລະ ປັບປຸງກ່ອນທີ່ຈະເຮັດຊໍ້າຄືນການດໍາເນີນງານ.
• ຂໍ້ຜິດພາດ 500 ທີ່ຖືກເກັບໄວ້ສາມາດຫຼິ້ນຄືນໄດ້ຫຼັງຈາກການເຊື່ອມຕໍ່ກັບມາໃຊ້ໄດ້. ການດໍາເນີນງານຕົ້ນສະບັບອາດຈະມີຜົນຂ້າງຄຽງ; ໃຊ້ວັດຖຸທີ່ກ່ຽວຂ້ອງ, ຄໍາຮ້ອງຂໍ Dashboard ແລະ webhooks ເພື່ອກໍານົດຜົນໄດ້ຮັບຂອງມັນ.
• API v2 ໃຊ້ຄວາມໝາຍການຫຼິ້ນຄືນທີ່ແຕກຕ່າງກັນ. ກະແຈບໍ່ໄດ້ສ້າງການສົ່ງມອບທີ່ແນ່ນອນພຽງຄັ້ງດຽວທົ່ວໄປສໍາລັບອີເມວ, ສິນຄ້າຄົງຄັງ ແລະ ທຸກການດໍາເນີນງານຖານຂໍ້ມູນທ້ອງຖິ່ນ.

ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

ການໝົດເວລາຍົກເລີກການຊໍາລະເງິນຂອງທ່ານບໍ?

0:00 ທ່ານຄິດວ່າການໝົດເວລາມີຄວາມໝາຍວ່າການຊໍາລະເງິນຂອງທ່ານລົ້ມເຫລວ. ເຊີບເວີສາມາດສໍາເລັດໃນຂະນະທີ່ຄໍາຕອບຫາຍໄປ, ເຮັດໃຫ້ການຈ່າຍເງິນຂອງທ່ານສະແດງຢ່າງໝັ້ນໃຈວ່າບໍ່ມີຫຍັງເລີຍ. ເປັນຫຍັງການລອງໃໝ່ຈຶ່ງສາມາດຄິດຄ່າບໍລິການອີກຄັ້ງ? Stripe ຈື່ການພະຍາຍາມໄດ້ແນວໃດ? ເຈົ້າຄວນຢຸດການລອງໃໝ່ເມື່ອໃດ? ແລະ ຈື່ລາຍລະອຽດທີ່ບໍ່ດີອັນໜຶ່ງໄວ້. ຂໍ້ຜິດພາດທີ່ຈື່ໄວ້ສາມາດຢູ່ລອດໄດ້ດົນກວ່າບັນຫາເຄືອຂ່າຍ.

0:17 ພວກເຮົາຈະກັບມາເບິ່ງເລື່ອງນັ້ນ. ນີ້ແມ່ນ The Daily Diff, ພາຍໃຕ້ຜ້າຄຸມ.

ກະແຈຄວາມຄົງຕົວລະບຸຫຍັງ?

0:21 ຄວາມຄົງຕົວໝາຍເຖິງການເຮັດຊໍ້າຄືນການດໍາເນີນງານມີຜົນກະທົບທີ່ຕັ້ງໃຈຄືກັນກັບການເຮັດ ມັນຄັ້ງດຽວ. ກະແຈຄວາມຄົງຕົວຕິດປ້າຍການກະທໍາຢ່າງມີເຫດຜົນອັນດຽວ. Stripe's API version one ຮັບຮູ້ປ້າຍນັ້ນໃນການລອງໃໝ່ ແລະ ຫຼິ້ນຄືນຄໍາຕອບທີ່ບັນທຶກ ໄວ້. ລອງນຶກພາບເຖິງການຊື້ກາເຟ. Stripe ສໍາເລັດຄໍາຮ້ອງຂໍການຊໍາລະເງິນຂອງທ່ານ, ແລະ ຄໍາຕອບກໍ່ຫາຍໄປເມື່ອກັບ ຄືນມາ. ລູກຄ້າເຫັນໜ້າຈໍໝຸນ. ທະນາຄານຂອງພວກເຂົາອາດຈະມີການຕີຄວາມໝາຍທີ່ໜ້າຕື່ນເຕັ້ນກວ່າ. ຄໍາຮ້ອງຂໍສ້າງທີ່ບໍ່ມີການປ້ອງກັນສາມາດເຮັດຊໍ້າຜົນຂ້າງຄຽງໄດ້.

ກະແຈດຽວກັນເຮັດໃຫ້ການລອງໃໝ່ປອດໄພໄດ້ແນວໃດ?

0:45 ຕິດກະແຈທີ່ເປັນເອກະລັກກ່ອນການພະຍາຍາມຄັ້ງທໍາອິດ ແລະ ເກັບມັນໄວ້ສໍາລັບການລອງໃໝ່. ຖ້າແອັບພລິເຄຊັນຂອງທ່ານເລີ່ມຕົ້ນໃໝ່, ໃຫ້ຮັກສາກະແຈນັ້ນໄວ້ກັບການດໍາເນີນງານໃນບັນທຶກ ຂອງທ່ານ. ສໍາລັບ Stripe's version one API, ເມື່ອການປະຕິບັດຈຸດສິ້ນສຸດເລີ່ມຕົ້ນ, ສະຖານະ ແລະ ເນື້ອໃນຂອງຄໍາຮ້ອງຂໍທໍາອິດຈະຖືກບັນທຶກໄວ້. ສົ່ງກະແຈ ແລະ ພາລາມິເຕີອັນດຽວກັນອີກຄັ້ງ, ແລະ Stripe ຈະສົ່ງຄືນຄໍາຕອບທີ່ບັນທຶກໄວ້. ກາເຟຍັງຄົງຢູ່ບ່ອນເກົ່າໃນຂະນະທີ່ໃບຮັບເງິນເດີນທາງອີກຄັ້ງ.

Stripe ບັນທຶກຫຍັງແທ້?

1:07 ນີ້ແມ່ນຄໍາເວົ້າຕົວຈິງຂອງ Stripe. ການລອງໃໝ່ດ້ວຍກະແຈດຽວກັນຈະສົ່ງຄືນຄໍາຕອບທີ່ບັນທຶກໄວ້, ລວມທັງຂໍ້ຜິດພາດຫ้าร້ອຍ. ເອກະສານເຮັດວຽກຫຼາຍກວ່າຕົວຊ່ວຍການລອງໃໝ່ທີ່ຕັ້ງຊື່ຢ່າງມີຄວາມຫວັງຂອງທ່ານ. ລູກຄ້າກົດອີກຄັ້ງ. ແອັບຂອງທ່ານຕັດສິນໃຈວ່າຈະສືບຕໍ່ການຊື້ທີ່ຄ້າງຢູ່ ຫຼື ເລີ່ມຕົ້ນການຊື້ໃໝ່ອີກ ອັນ. ກາເຟໃໝ່ຢ່າງແທ້ຈິງຈະໄດ້ຮັບກະແຈໃໝ່. ກະແຈໃໝ່ສໍາລັບທຸກການລອງໃໝ່ເຄືອຂ່າຍເຮັດໃຫ້ການປ້ອງກັນລົ້ມເຫຼວ.

1:27 ພາລາມິເຕີທີ່ແຕກຕ່າງກັນດ້ວຍກະແຈດຽວກັນເຮັດໃຫ້ເກີດຄວາມບໍ່ກົງກັນ.

ຈະເກີດຫຍັງຂຶ້ນເມື່ອຄໍາຮ້ອງຂໍປ່ຽນແປງ?

1:30 ຖ້າພາລາມິເຕີລົ້ມເຫຼວໃນການຢືນຢັນ, ຫຼື ຄໍາຮ້ອງຂໍອື່ນທີ່ມີກະແຈນັ້ນຍັງຄົງ ປະຕິບັດຢູ່, Stripe ບໍ່ບັນທຶກຜົນລັບທີ່ຄົງຕົວສໍາລັບການພະຍາຍາມນັ້ນ. ຄໍາຮ້ອງຂໍເຫຼົ່ານັ້ນສາມາດລອງໃໝ່ໄດ້. ຄໍາຮ້ອງຂໍທີ່ແຂ່ງຂັນກັນໄດ້ຮັບຂໍ້ຂັດແຍ່ງ. ເຫຼົ່ານີ້ແມ່ນກົດລະບຽບຂອງເວີຊັນໜຶ່ງ. ເວີຊັນສອງປະຕິບັດແຕກຕ່າງກັນ. ຫົວຂໍ້ບໍ່ສາມາດສັນຍາການສົ່ງມອບພຽງຄັ້ງດຽວທົ່ວລະບົບຂອງທ່ານໄດ້. ອີເມວ, ສິນຄ້າຄົງຄັງ ແລະ ຖານຂໍ້ມູນຂອງທ່ານແຕ່ລະອັນຕ້ອງການການຈັດການຄວາມລົ້ມເຫຼວ.

1:52 ກະແຈປ້ອງກັນການດໍາເນີນງານພາຍໃນຂອບເຂດທີ່ໄດ້ລະບຸໄວ້. Stripe ຮັກສາກະແຈເວີຊັນໜຶ່ງໄວ້ຢ່າງໜ້ອຍຊາວສີ່ຊົ່ວໂມງ ແລະ ສາມາດລຶບ

ຜົນລັບທີ່ຈື່ໄວ້ປອດໄພທີ່ຈະລອງໃໝ່ໄດ້ດົນປານໃດ?

1:59 ພວກມັນອອກໄດ້ຫຼັງຈາກນັ້ນ. ກະແຈທີ່ຖືກລຶບສາມາດປະຕິບັດຄໍາຮ້ອງຂໍໃໝ່ໄດ້. ຮັກສາການລອງໃໝ່ທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂໄວ້ພາຍໃນມື້ທໍາອິດ. ຫຼັງຈາກນັ້ນ, ໃຫ້ຢຸດ ແລະ ປັບປຸງຜົນລັບຕົ້ນສະບັບ. ໃຊ້ exponential backoff ແລະ jitter ເພື່ອໃຫ້ເຊີບເວີມີເວລາຫາຍໃຈ. ຖ້າບໍ່ດັ່ງນັ້ນການລອງໃໝ່ຈະສ້າງແຖວຢູ່ນອກຮ້ານກາເຟທີ່ຖືກໄຟໄໝ້. ຫ້ອງສະໝຸດຂອງ Stripe ຈັດການການລອງໃໝ່, ແຕ່ກວດເບິ່ງຄ່າເລີ່ມຕົ້ນຂອງຫ້ອງສະໝຸດຂອງທ່ານ. ຂໍ້ຜິດພາດທີ່ຕິດຂັດນັ້ນແມ່ນບັນຫາ.

ເປັນຫຍັງຂໍ້ຜິດພາດທີ່ຈື່ໄວ້ຈຶ່ງກັບມາອີກ?

2:20 ຄໍາຕອບຫ້າຮ້ອຍທີ່ຖືກເກັບໄວ້ຈະສືບຕໍ່ຫຼິ້ນຄືນຫຼັງຈາກການເຊື່ອມຕໍ່ກັບມາໃຊ້ໄດ້. ການດໍາເນີນງານຕົ້ນສະບັບອາດຈະສ້າງຜົນຂ້າງຄຽງ. ແກ້ໄຂຜົນລັບຂອງມັນໂດຍໃຊ້ວັດຖຸ, Dashboard ແລະ webhooks. ກະແຈໃໝ່ສາມາດເຮັດຊໍ້າການກະທໍາໄດ້. ຖ້າທ່ານຕ້ອງການອ່ານສິ່ງນີ້ຫຼາຍກວ່າທີ່ຈະໄດ້ຍິນຂ້ອຍເວົ້າ, The Daily Diff ຈະຖືກສົ່ງເຂົ້າກ່ອງຈົດໝາຍຂອງທ່ານ ທຸກເຊົ້າ, ຟຣີທີ່ the daily diff dot dev, ລິ້ງຢູ່ລຸ່ມນີ້.

ຂ້ອຍຈະສົ່ງປຸ່ມລອງໃໝ່ດ້ວຍສັນຍານີ້ບໍ?

2:39 ຄໍາຕັດສິນ, ພາຍໃຕ້ຜ້າຄຸມ. Ship it. ຂ້ອຍຈະສົ່ງກະແຈທີ່ໝັ້ນຄົງດ້ວຍການລອງໃໝ່ທີ່ກໍານົດໄວ້ ແລະ ການປັບປຸງ, ເພື່ອໃຫ້ລູກຄ້າໄດ້ກາເຟໂດຍບໍ່ຕ້ອງລົງທຶນໃນການສຶກສາລະບົບແຈກຢາຍຂອງທ່ານ. ແລະ ນັ້ນແມ່ນ The Daily Diff ສໍາລັບມື້ນີ້. ຂ້ອຍຄື Niko ຈາກ Axrisi. ລວມເຂົ້າຢ່າງມີຄວາມຮັບຜິດຊອບ.

ແຫຼ່ງຂໍ້ມູນ

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor