प्रतिक्रिया हराउँदा Stripe ले तपाईको अनुरोध सम्झन्छ

यो भिडियोले के समेट्छ

• आइडम्पोटेन्सीले सञ्चालन दोहोऱ्याउँदा हुने अपेक्षित प्रभावसँग सम्बन्धित छ। Stripe API v1 ले दस्तावेज गरिएको सुरक्षित-प्रतिक्रिया रिप्ले सम्झौता थप्छ।
• एउटै तार्किक कार्यको पुन:प्रयासले एउटै कुञ्जी र प्यारामिटरहरू प्रयोग गर्दछ। SDK कलहरू वा अनुप्रयोग पुन:सुरुहरूमा सञ्चालन कुञ्जीलाई निरन्तर राख्नुहोस्; साँच्चिकै नयाँ कार्यलाई यसको आफ्नै कुञ्जी चाहिन्छ।
• एन्डपोइन्ट कार्यान्वयन सुरु भएपछि, Stripe API v1 ले पहिलो अनुरोधको स्थिति र मुख्य भाग, 500 त्रुटिहरू सहित, बचत गर्दछ र पुन:प्रयासहरूमा त्यो सुरक्षित प्रतिक्रिया फिर्ता गर्दछ।
• एउटै कुञ्जीको साथ परिवर्तन गरिएका प्यारामिटरहरूले बेमेल उत्पन्न गर्दछ। प्रमाणीकरण विफलता र समवर्ती कार्यान्वयन द्वन्द्वहरूले त्यो प्रयासको लागि कुनै आइडम्पोटेन्ट परिणाम बचत गर्दैन र पुन:प्रयास गर्न सकिन्छ।
• Stripe ले API v1 कुञ्जीहरू कम्तिमा 24 घण्टाका लागि राख्छ र त्यसपछि तिनीहरूलाई हटाउन सक्छ। समाधान नभएका नेटवर्क पुन:प्रयासहरूलाई पहिलो 24 घण्टामा सीमित गर्नुहोस्, त्यसपछि सञ्चालन दोहोऱ्याउनु अघि रोक्नुहोस् र मेलमिलाप गर्नुहोस्।
• कनेक्टिभिटी रिकभर भएपछि पनि क्यास गरिएको 500 बारम्बार रिप्ले भइरहन सक्छ। मूल सञ्चालनको साइड इफेक्ट हुन सक्छ; यसको परिणाम स्थापित गर्न सान्दर्भिक वस्तु, ड्यासबोर्ड अनुरोध र वेबहुकहरू प्रयोग गर्नुहोस्।
• API v2 ले फरक रिप्ले सिमान्टिक्स प्रयोग गर्दछ। एउटा कुञ्जीले इमेल, इन्भेन्टरी र प्रत्येक स्थानीय डेटाबेस सञ्चालनका लागि विश्वव्यापी रूपमा ठ्याक्कै एक पटक डेलिभरी स्थापित गर्दैन।

अनुवादित ट्रान्सक्रिप्ट

मूल अंग्रेजी कथाबाट अनुवादित। उपलब्ध अडियो र क्याप्सनहरू YouTube द्वारा नियन्त्रित हुन्छन्।

के टाइमआउटले तपाईको भुक्तानी रद्द गर्यो?

0:00 तपाईंलाई लाग्छ कि टाइमआउटको मतलब तपाईंको भुक्तानी असफल भयो। सर्भरले जवाफ हराउँदा पनि काम पूरा गर्न सक्छ, तपाईंको चेकआउट आत्मविश्वासपूर्वक केही पनि नदेखाएर। पुन:प्रयासले किन फेरि शुल्क लगाउन सक्छ? Stripe ले प्रयास कसरी सम्झन्छ? तपाईंले पुन:प्रयास गर्न कहिले रोक्नुपर्छ? र एउटा खराब विवरण मनमा राख्नुहोस्। याद गरिएको त्रुटि नेटवर्क समस्याभन्दा बढी टिक्न सक्छ।

0:17 हामी त्यसमा फर्कनेछौं। यो The Daily Diff, पर्दा पछाडि हो।

आइडम्पोटेन्सी कुञ्जीले के पहिचान गर्छ?

0:21 आइडम्पोटेन्सीको अर्थ एउटा सञ्चालन दोहोऱ्याउँदा एक पटक गर्दा जस्तै एउटै अपेक्षित प्रभाव हुन्छ। आइडम्पोटेन्सी कुञ्जीले एउटा तार्किक कार्यलाई लेबल गर्दछ। Stripe को API संस्करण एकले पुन:प्रयासहरूमा त्यो लेबल चिन्छ र सुरक्षित प्रतिक्रिया रिप्ले गर्दछ। कफी किनेको कल्पना गर्नुहोस्। Stripe ले तपाईंको भुक्तानी अनुरोध पूरा गर्छ, र प्रतिक्रिया घर फर्कने क्रममा हराउँछ, ग्राहकले स्पिनर देख्छ। उनीहरूको बैंकको अझ रोमाञ्चक व्याख्या हुन सक्छ। असुरक्षित सिर्जना अनुरोधले साइड इफेक्ट दोहोऱ्याउन सक्छ।

एउटै कुञ्जीले कसरी पुन:प्रयासलाई सुरक्षित बनाउँछ?

0:45 पहिलो प्रयास अघि एउटा अद्वितीय कुञ्जी संलग्न गर्नुहोस् र यसलाई पुन:प्रयासका लागि राख्नुहोस्। यदि तपाईंको अनुप्रयोग पुन:सुरु भयो भने, तपाईंको रेकर्डमा सञ्चालनसँग त्यो कुञ्जी सुरक्षित गर्नुहोस्। Stripe को संस्करण एक API को लागि, एकपटक एन्डपोइन्ट कार्यान्वयन सुरु भएपछि, पहिलो अनुरोधको स्थिति र मुख्य भाग बचत गरिन्छ। एउटै कुञ्जी र प्यारामिटरहरू फेरि पठाउनुहोस्, र Stripe ले सुरक्षित प्रतिक्रिया फिर्ता गर्दछ। कफी त्यहीँ रहन्छ जबकि यसको रसिद फेरि यात्रा गर्छ।

Stripe ले ठ्याक्कै के बचत गर्छ?

1:07 यहाँ Stripe को वास्तविक शब्द छ। एउटै कुञ्जीका साथ गरिएका पुन:प्रयासहरूले सुरक्षित प्रतिक्रिया फिर्ता गर्दछ, पाँच सय त्रुटिहरू सहित। दस्तावेजले तपाईंको आशावादी नाम गरिएको पुन:प्रयास सहायक भन्दा बढी काम गर्छ। ग्राहकले फेरि ट्याप गर्छ। तपाईंको एपले त्यो पेन्डिङ खरिद पुन:सुरु गर्छ वा अर्को सुरु गर्छ भनेर निर्णय गर्छ। साँच्चिकै नयाँ कफीले नयाँ कुञ्जी पाउँछ। प्रत्येक नेटवर्क पुन:प्रयासको लागि ताजा कुञ्जीले सुरक्षालाई हराउँछ।

1:27 एउटै कुञ्जीका साथ फरक प्यारामिटरहरूले बेमेल उत्पन्न गर्दछ।

अनुरोध परिवर्तन हुँदा के हुन्छ?

1:30 यदि प्यारामिटरहरू प्रमाणीकरणमा असफल भए, वा त्यो कुञ्जीको साथ अर्को अनुरोध अझै कार्यान्वयन भइरहेको छ भने, Stripe ले त्यो प्रयासको लागि कुनै आइडम्पोटेन्ट परिणाम बचत गर्दैन। ती अनुरोधहरू पुन:प्रयास गर्न सकिन्छ। दौडिरहेको अनुरोधमा द्वन्द्व हुन्छ। यी संस्करण एक नियमहरू हुन्। संस्करण दुई फरक व्यवहार गर्दछ। हेडरले तपाईंको प्रणालीभरि ठ्याक्कै एक पटक डेलिभरीको प्रतिज्ञा गर्न सक्दैन। इमेल, इन्भेन्टरी र तपाईंको डेटाबेसलाई प्रत्येकलाई त्रुटि ह्यान्डलिंग चाहिन्छ।

1:52 कुञ्जीले यसको दस्तावेज गरिएको दायरा भित्रको सञ्चालनलाई सुरक्षित गर्दछ। Stripe ले संस्करण एक कुञ्जीहरू कम्तिमा चौबीस घण्टाका लागि राख्छ र त्यसपछि

याद गरिएको परिणाम पुन:प्रयास गर्न कति समयसम्म सुरक्षित हुन्छ?

1:59 तिनीहरूलाई हटाउन सक्छ। हटाइएको कुञ्जीले नयाँ अनुरोध कार्यान्वयन गर्न सक्छ। समाधान नभएका पुन:प्रयासहरू पहिलो दिन भित्र राख्नुहोस्। त्यसभन्दा बाहिर, रोक्नुहोस् र मूल परिणामको मेलमिलाप गर्नुहोस्। सर्भरलाई सास फेर्ने ठाउँ दिन एक्स्पोनेन्सियल ब्याकअफ र जिटर प्रयोग गर्नुहोस्। अन्यथा पुन:प्रयासहरू जलेको कफी पसल बाहिर लाइन लाग्छन्। Stripe को पुस्तकालयहरूले पुन:प्रयासहरू ह्यान्डल गर्छन्, तर तपाईंको पुस्तकालयको पूर्वनिर्धारित सेटिङहरू जाँच गर्नुहोस्। त्यो टाँसिने त्रुटि नै समस्या हो।

याद गरिएको त्रुटि किन बारम्बार आउन सक्छ?

2:20 कनेक्टिभिटी रिकभर भएपछि पनि क्यास गरिएको पाँच सय प्रतिक्रिया बारम्बार रिप्ले भइरहन सक्छ। मूल सञ्चालनले साइड इफेक्टहरू उत्पन्न गरेको हुन सक्छ। वस्तुहरू, ड्यासबोर्ड र वेबहुकहरू प्रयोग गरेर यसको परिणाम समाधान गर्नुहोस्। नयाँ कुञ्जीले कार्य दोहोऱ्याउन सक्छ। यदि तपाईं मलाई यो भन्न सुन्नुको सट्टा पढ्न चाहनुहुन्छ भने, diff हरेक बिहान तपाईंको इनबक्समा आउँछ, daily diff dot dev मा निःशुल्क, लिङ्क तल छ।

के म यो सम्झौताको साथ पुन:प्रयास बटन पठाउँछु?

2:39 निर्णय, पर्दा पछाडि। SHIP IT. म सीमित पुन:प्रयास र मेलमिलापका साथ स्थिर कुञ्जीहरू पठाउँछु, ताकि ग्राहकहरूले तपाईंको वितरित प्रणाली शिक्षामा लगानी नगरी कफी पाउँछन्। र आजको लागि यति नै diff। म Axrisi बाट Niko हुँ। जिम्मेवारीपूर्वक मर्ज गर्नुहोस्।

स्रोतहरू

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