टाइम आउट आउट POST अनुरोधों से निपटने के लिए कैसे करें

Question

एक विश्वसनीय एसओए में, मान लीजिए कि मैं AJAX के माध्यम से एक POST अनुरोध जारी करता हूं लेकिन मुझे अनुरोध समय से पहले कोई प्रतिक्रिया नहीं मिलती है। आगे मान लें कि अनुरोध का पुन: जमा करना हानिकारक होगा। पोस्ट बेवकूफ नहीं है। उदाहरण के लिए, शायद मैं पैसे का बैंक हस्तांतरण पोस्ट कर रहा हूं। अगर मुझे कोई प्रतिक्रिया नहीं मिलती है, तो मुझे नहीं पता कि सर्वर ने अनुरोध संसाधित किया है या नहीं।

इस बात से निपटने का सबसे अच्छा अभ्यास क्या है, मानते हैं कि मेरे पास क्लाइंट-साइड और सेवा पक्ष पर नियंत्रण है?

मेरा प्रारंभिक विचार प्रत्येक POST अनुरोध के साथ एक nonce (यानी एक छद्म-आईडी; कुछ अद्वितीय पहचानकर्ता) शामिल करना है; जैसे शायद if-None-match हेडर में एक मान। इस दृष्टिकोण के साथ, क्लाइंट-साइड एक ही छद्म-आईडी के साथ एक समयबद्ध अनुरोध को प्रोग्रामेटिक रूप से फिर से जारी कर सकता है और यदि सर्वर दोहराना मूल्य रखता है तो सर्वर इसे अस्वीकार कर सकता है।

Answer 1

तरीके हल करने के लिए इस

1. वर्तमान स्थिति हासिल करने की कोशिश करना मैं के बारे में सुना है की एक संख्या हैं।

   सेवा डिज़ाइन करें ताकि यदि कोई पोस्ट विफल हो जाए, तो क्लाइंट एक ही संसाधन पर एक GET जारी कर सकता है और लौटाए गए डेटा के आधार पर, वे यह निर्धारित कर सकते हैं कि POST सफल नहीं हुआ था या नहीं।

   इस दृष्टिकोण के साथ समस्या उन मामलों में है जहां POST संग्रह में एक नया आइटम बनाता है, क्लाइंट के लिए यह निर्धारित करना मुश्किल हो सकता है कि पोस्ट सफल था या नहीं (यानी, मेरी पोस्ट ने उस आइटम को जोड़ा या किया किसी और की?)

2. हैं-मैच

   उपयोग दोहराया जा रहा से पोस्ट को रोकने के लिए If-Match हैडर। उदाहरण के लिए, यदि POST संग्रह में कोई आइटम जोड़ रहा है, और संग्रह में वर्तमान में का ETag है। यदि If-Match737060cd8c284d8af7ad3082f209582d का उपयोग POST पर किया जाता है, तो POST केवल तभी सफल होगा जब संग्रह का ETag अभी भी 737060cd8c284d8af7ad3082f209582d है, जो आइटम को जोड़ देगा और परिणाम संग्रह के लिए एक नया ETag होगा। इस चरण में POST को दोहराएं बस 412 Precondition Failed वापस आ जाएगा।

   इस दृष्टिकोण के साथ समस्या तब होती है जब आपको 412 Precondition Failed मिलता है, तो आप यह सुनिश्चित नहीं कर सकते कि आपके POST संग्रह या किसी और के संशोधित हैं या नहीं।

3. पोस्ट तो डाल

   आपकी सेवा डिजाइन एक पोस्ट से डेटा जारी रहती है कभी नहीं करने के लिए। इसके बजाय POST POST सामग्री के साथ एक अस्थायी संसाधन बनाता है, जो "लंबित" स्थिति में है। यह अस्थायी संसाधन तब एक पुट के साथ "प्रतिबद्ध" होता है। इस दृष्टिकोण के साथ आप परवाह नहीं है कि आपका पोस्ट समय समाप्त हो गया है, बस POST का अनुरोध करें और इस बार आपको उम्मीद है कि आप अपना अस्थायी संसाधन प्राप्त करेंगे। यदि संसाधन समय समाप्त करने के लिए PUT है, तो आप परवाह नहीं है, क्योंकि PUT बेवकूफ है।

   अस्थायी संसाधनों और ग्राहक में आवश्यक अतिरिक्त प्रयासों को प्रबंधित करने के लिए आवश्यक अतिरिक्त कार्य इस दृष्टिकोण का एकमात्र वास्तविक नकारात्मक कार्य है।

   अद्यतन

4. Nonce

   एक अस्थायी रूप से का उपयोग (ए.के.अनुरोध में एक संदेश आईडी, लेनदेन आईडी, अनुरोध आईडी, सहसंबंध आईडी) इस समस्या को हल करने के लिए एक आम दृष्टिकोण है; हालांकि इसमें स्केलेबिलिटी मुद्दे हो सकते हैं। यदि आप पिछले पोस्ट का उपयोग करने वाले सभी POSTs को अस्वीकार करने के लिए प्रतिबद्ध हैं, तो आपको यह निर्धारित करने के लिए मौजूदा POST रिकॉर्ड स्कैन करने की आवश्यकता है कि पहले नॉन का उपयोग किया गया है या नहीं। कोई समस्या नहीं है जब आपके पास केवल कुछ हज़ार पोस्ट हैं, लेकिन जब आपके पास लाखों लोग होते हैं तो यह समस्याग्रस्त हो सकता है (विशेष रूप से यदि आपने nonces को ऐसे तरीके से संग्रहीत नहीं किया है जो क्वेरी करने के लिए तेज़ हैं)।

   आप किसी भी समय सीमा (उदाहरण के लिए, अंतिम 24 घंटे) के भीतर पिछले गैर-उपयोग का उपयोग करने वाले सभी POSTs को अस्वीकार करने के लिए अपनी प्रतिबद्धता को कम करके इसे कम कर सकते हैं, लेकिन यदि पहली पोस्ट समय समाप्त हो जाती है और क्लाइंट उस समय सीमा के लिए डिस्कनेक्ट हो जाता है, तो वे एक ही पुरानी स्थिति में वापस आ गए हैं, जहां वे नहीं जानते कि पहला पोस्ट सफल था या नहीं और यह निर्धारित करने का कोई तरीका नहीं है कि उन्हें फिर से करना चाहिए या नहीं।