के त्यो समय सकिएको पेसले साँच्चै तपाईंको काम सुरक्षित गर्‍यो?

बटन घुमिरहेको छ, ट्याबले त्रुटि देखाइरहेको छ, र दस मिनेट भरेको तपाईंको फारम हराएको छ। तपाईंलाई थाहा छैन कि जडान मर्नु अघि लेखन पुग्यो कि पुगेन। त्यो अज्ञातलाई असफलता मान्ने बित्तिकै नक्कल टिप्पणी, दोहोरो अर्डर र बारम्बार आउने सहयोग टिकट बन्छन्।

निश्चित क्रममा पुनःप्राप्त गर्नुहोस्: पाठ राख्नुहोस्, नतिजा खोज्नुहोस्, र त्यसपछि मात्र दोस्रो पेस स्वीकार्य छ कि छैन निर्णय गर्नुहोस्।

पाठ र समय-छापबाट सुरु गर्नुहोस्

अरू केही छुनु अघि पृष्ठबाट सामग्री प्रतिलिपि गर्नुहोस्, ब्राउजरले अझै फाँटमा राखेको मस्यौदासमेत। समय, तपाईं भएको पृष्ठ र गरेको कार्य लेख्नुहोस्, किनकि यी तीन विवरणले नै बाँकी जाँच सम्भव बनाउँछन्। ट्याब अझै खुला छ भने नेटवर्क प्रविष्टि पढुञ्जेल खुला राख्नुहोस्। पाठ सुरक्षित गर्न केही खर्च हुँदैन, र गुमाउनु सम्पूर्ण कामको खर्च हो।

त्यसपछि तपाईंले साँच्चै देख्न सक्ने दुई प्रकारका खराबी छुट्याउनुहोस्। अनुरोधको बीचमा टुटेको जडान र त्रुटिसहित जवाफ दिएको सर्भर नेटवर्क प्यानलमा फरक देखिन्छन्, र एपको निर्णयबारे केही भन्ने दोस्रोले मात्र हो।

एपको आफ्नै दृश्यमा नतिजा खोज्नुहोस्

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

नतिजा त्यहाँ छ भने तपाईं सक्नुभयो र त्रुटि लेखनको होइन, जवाफको बाटोको हो। छैन भने, एपले अझै त्यसलाई पक्का नगरेको हुनसक्ने सम्भावना राख्नुहोस्: लाइनमा रहेको काम, ढिलो पठन दृश्य वा पछि परेको प्रतिलेखले सफल लेखन केही समय लुकाउन सक्छ।

निष्कर्ष निकाल्नु अघि त्यसलाई निश्चित दोस्रो हेराइ दिनुहोस्, र दुवै जाँचको समय लेख्नुहोस्। बीस सेकेन्डको अन्तरमा गरिएका दुई जाँच दस मिनेटको अन्तरमा गरिएका दुई जाँचभन्दा धेरै कमजोर प्रमाण हुन्।

दोस्रो पेस सुरक्षित छ कि छैन निर्णय गर्नुहोस्

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

तपाईंले क्लाइन्ट सम्हाल्नुहुन्छ भने, API ले अभिलेख गरेको पुनःप्रयास वा इडेम्पोटेन्सी संयन्त्र प्रयोग गर्नुहोस्, र हरेक प्रयासका लागि नयाँ कुञ्जी बनाउनुको सट्टा त्यसलाई त्यही तार्किक सञ्चालनसँग जोड्नुहोस्। ट्रेसिङका लागि प्रयोग हुने अनुरोध पहिचानकर्ता नक्कल दबाउने कुञ्जी होइन, जबसम्म सर्भरले त्यसलाई त्यस्तै मान्दैन।

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

कुञ्जीले मात्र तब मद्दत गर्छ जब सेवाले त्यसलाई सञ्चालनसँगै भण्डारण गर्छ र दोहोरिएमा मूल नतिजा फर्काउँछ। उत्पादनमा त्यसलाई भर पर्नु अघि स्टेजिङ अन्त्य बिन्दुमा त्यो व्यवहार परीक्षण गर्नुहोस्।

फेरि केही थिच्नु अघि प्रमाण जम्मा गर्नुहोस्

त्रुटिको स्क्रिनसटको सट्टा नेटवर्क प्रविष्टि राख्नुहोस्। अनुरोध विधि, URL, जवाफ वा समयसीमा र त्यो कहिले भयो भन्ने नै प्रशासकले एपका अभिलेखसँग मिलाउन सक्ने कुरा हुन्। प्रविष्टिलाई आदेशका रूपमा निर्यात वा प्रतिलिपि गर्नुहोस्, त्यसपछि प्रतिलिपिबाट कुकी, प्राधिकरण हेडर र कुनै पनि निजी सामग्री हटाए मात्र। आफ्नै सत्र अक्षुण्ण राख्नुहोस्, र समातिएको प्रमाणपत्र भएको अनुरोध कहिल्यै छोटो बाटोका रूपमा पुनः नचलाउनुहोस्।

सेवा मालिकलाई एउटा ठोस प्रश्न सोध्नुहोस्: यो सामग्रीसहित यो समयमा सञ्चालन सफल भयो, र त्यसको सन्दर्भ छ? यो प्रश्नको जवाफ छ, तर "साइट बिग्रियो" को जवाफ छैन।

यो अभ्यासको उद्देश्य कार्य ठ्याक्कै एक पटक भयो भनी स्थापित गर्नु हो। तपाईंले बन्द गर्न सक्ने त्रुटि सन्देश तपाईंले विश्वास गर्न सक्ने अभिलेखसँग बराबर हुँदैन, र अरू केही पठाउनु अघि तपाईंलाई दोस्रो चाहिन्छ।