هنگامی که پاسخ ناپدید می شود، Stripe درخواست شما را به خاطر می آورد

این ویدیو چه مواردی را پوشش می‌دهد

• Idempotency مربوط به تأثیر مورد نظر از تکرار یک عملیات است. Stripe API v1 یک قرارداد بازپخش پاسخ ذخیره‌شده‌ی مستند اضافه می‌کند.
• تلاش مجدد برای همان اقدام منطقی از همان کلید و پارامترها استفاده می‌کند. کلید عملیات را در بین تماس‌های جداگانه SDK یا راه‌اندازی مجدد برنامه حفظ کنید؛ یک اقدام واقعاً جدید به کلید مخصوص خود نیاز دارد.
• پس از شروع اجرای نقطه پایانی، Stripe API v1 وضعیت و بدنه اولین درخواست را، از جمله خطاهای 500، ذخیره می‌کند و آن پاسخ ذخیره‌شده را در هنگام تلاش‌های مجدد برمی‌گرداند.
• پارامترهای تغییر یافته با همان کلید، عدم تطابق ایجاد می‌کنند. خطاهای اعتبارسنجی و تضادهای اجرای همزمان هیچ نتیجه‌ی idempotency برای آن تلاش ذخیره نمی‌کنند و می‌توانند دوباره امتحان شوند.
• Stripe کلیدهای API v1 را حداقل 24 ساعت نگهداری می‌کند و پس از آن می‌تواند آنها را حذف کند. تلاش‌های مجدد شبکه حل‌نشده را به 24 ساعت اول محدود کنید، سپس قبل از تکرار عملیات، توقف کرده و نتیجه را تطبیق دهید.
• یک خطای 500 ذخیره‌شده می‌تواند پس از بازیابی اتصال، به بازپخش ادامه دهد. عملیات اصلی ممکن است عوارض جانبی داشته باشد؛ برای تعیین نتیجه‌ی آن از شیء مربوطه، درخواست داشبورد و وب‌هوک‌ها استفاده کنید.
• API v2 از معنای بازپخش متفاوتی استفاده می‌کند. یک کلید، تحویل دقیقاً یک‌باره جهانی را برای ایمیل، موجودی و هر عملیات پایگاه داده محلی ایجاد نمی‌کند.

رونوشت ترجمه شده

ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.

آیا یک وقفه پرداخت شما را لغو کرد؟

0:00 شما فکر می‌کنید یک وقفه به معنای عدم موفقیت پرداخت شما است. سرور می‌تواند در حالی که پاسخ ناپدید می‌شود، کار را تمام کند، و صندوق پرداخت شما با اطمینان مطلقاً هیچ چیز را نشان نمی‌دهد. چرا یک تلاش مجدد می‌تواند دوباره هزینه دریافت کند؟ Stripe چگونه یک تلاش را به خاطر می‌آورد؟ چه زمانی باید از تلاش مجدد دست بردارید؟ و یک نکته‌ی ناخوشایند را به خاطر بسپارید. یک خطای به خاطر سپرده شده می‌تواند بیشتر از مشکل شبکه دوام بیاورد.

0:17 به آن برمی‌گردیم. این The Daily Diff است، زیر کاپوت.

یک کلید idempotency چه چیزی را شناسایی می‌کند؟

0:21 Idempotency به این معنی است که تکرار یک عملیات همان تأثیر مورد نظر انجام آن را یک بار دارد. یک کلید idempotency یک اقدام منطقی را برچسب‌گذاری می‌کند. نسخه یک API استرایپ آن برچسب را در تلاش‌های مجدد می‌شناسد و یک پاسخ ذخیره‌شده را بازپخش می‌کند. خرید یک قهوه را تصور کنید. استرایپ درخواست پرداخت شما را تکمیل می‌کند و پاسخ در راه بازگشت به خانه گم می‌شود. مشتری یک نماد چرخان می‌بیند. بانک آنها ممکن است تفسیر هیجان‌انگیزتری داشته باشد. یک درخواست ایجاد محافظت‌نشده می‌تواند عوارض جانبی را تکرار کند.

چگونه یک کلید یکسان تلاش مجدد را ایمن می‌کند؟

0:45 قبل از اولین تلاش یک کلید منحصر به فرد اضافه کنید و آن را برای تلاش‌های مجدد نگه دارید. اگر برنامه شما دوباره راه‌اندازی شود، آن کلید را همراه با عملیات در سوابق خود حفظ کنید. برای API نسخه یک استرایپ، هنگامی که اجرای نقطه پایانی آغاز می‌شود، وضعیت و بدنه اولین درخواست ذخیره می‌شوند. همان کلید و پارامترها را دوباره ارسال کنید، و استرایپ پاسخ ذخیره‌شده را برمی‌گرداند. قهوه سر جای خود می‌ماند در حالی که رسید آن دوباره سفر می‌کند.

Stripe دقیقاً چه چیزی را ذخیره می‌کند؟

1:07 اینجا کلمات واقعی استرایپ است. تلاش‌های مجدد با همان کلید پاسخ ذخیره‌شده را برمی‌گرداند، از جمله خطاهای پانصد. مستندات بیشتر از راهنمای تلاش مجدد خوش‌بینانه شما کار می‌کنند. مشتری دوباره ضربه می‌زند. برنامه شما تصمیم می‌گیرد که آیا آن خرید در حال انتظار را از سر می‌گیرد یا یک خرید دیگر را شروع می‌کند. یک قهوه واقعاً جدید کلید جدیدی دریافت می‌کند. یک کلید جدید برای هر تلاش مجدد شبکه، محافظت را از بین می‌برد.

1:27 پارامترهای متفاوت با همان کلید، عدم تطابق را ایجاد می‌کنند.

چه اتفاقی می‌افتد وقتی درخواست تغییر می‌کند؟

1:30 اگر پارامترها در اعتبارسنجی شکست بخورند، یا یک درخواست دیگر با آن کلید هنوز در حال اجرا باشد، استرایپ هیچ نتیجه‌ی idempotency برای آن تلاش ذخیره نمی‌کند. آن درخواست‌ها را می‌توان دوباره امتحان کرد. یک درخواست رقابتی با یک تضاد روبرو می‌شود. اینها قوانین نسخه یک هستند. نسخه دو متفاوت عمل می‌کند. یک هدر نمی‌تواند تحویل دقیقاً یک‌باره را در سراسر سیستم شما تضمین کند. ایمیل، موجودی و پایگاه داده شما هر کدام نیاز به مدیریت خطا دارند.

1:52 کلید عملیات را در محدوده مستند خود محافظت می‌کند. استرایپ کلیدهای نسخه یک را حداقل بیست و چهار ساعت نگهداری می‌کند و پس از

تا چه مدت نتیجه‌ی به خاطر سپرده شده برای تلاش مجدد ایمن است؟

1:59 آن می‌تواند آنها را حذف کند. یک کلید حذف شده می‌تواند یک درخواست جدید را اجرا کند. تلاش‌های مجدد حل‌نشده را در روز اول نگه دارید. فراتر از آن، متوقف شوید و نتیجه اصلی را تطبیق دهید. از عقب‌نشینی نمایی و لرزش استفاده کنید تا به سرور فرصت تنفس بدهید. در غیر این صورت، تلاش‌های مجدد یک صف را در خارج از یک قهوه‌فروشی در حال سوختن تشکیل می‌دهند. کتابخانه‌های استرایپ تلاش‌های مجدد را مدیریت می‌کنند، اما پیش‌فرض‌های کتابخانه خود را بررسی کنید. آن خطای چسبنده، نکته‌ی اصلی است.

چرا یک خطای به خاطر سپرده شده می‌تواند مدام برگردد؟

2:20 یک پاسخ پنج‌صد ذخیره‌شده پس از بازیابی اتصال، به بازپخش ادامه می‌دهد. عملیات اصلی ممکن است عوارض جانبی ایجاد کرده باشد. نتیجه‌ی آن را با استفاده از اشیاء، داشبورد و وب‌هوک‌ها حل کنید. یک کلید جدید می‌تواند عمل را تکرار کند. اگر ترجیح می‌دهید این را بخوانید تا اینکه من آن را بگویم، The Daily Diff هر صبح به صورت رایگان به صندوق ورودی شما می‌رسد، در thedailydiff.dev، لینک زیر.

آیا با این قرارداد دکمه‌ی تلاش مجدد را ارسال می‌کردم؟

2:39 رای، زیر کاپوت. SHIP IT. من کلیدهای پایدار را با تلاش‌های مجدد محدود و تطبیق ارسال می‌کنم، تا مشتریان قهوه دریافت کنند بدون اینکه آموزش سیستم‌های توزیع شده شما را تامین مالی کنند. و این The Daily Diff امروز است. من نیکو از 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