प्रॉम्प्ट और संदर्भ
एक सर्च बॉक्स इनपुट बदलने पर सुझावों (suggestions) के लिए रिक्वेस्ट भेजता है। एक यूज़र तेजी से hello टाइप करता है, इसलिए ब्राउज़र h, he, hel, hell, और hello के लिए रिक्वेस्ट भेजता है, लेकिन नेटवर्क इस बात की गारंटी नहीं देता कि रिस्पॉन्स उसी क्रम में आएंगे। पुरानी रिक्वेस्ट सबसे अंत में पूरी हो सकती है और hello के परिणामों को hell से बदल सकती है; यूज़र इनपुट को साफ़ (clear) भी कर सकता है, नेटवर्क बदल सकता है, या पेज छोड़ सकता है।
रिक्वेस्ट लाइफसाइकिल, रिज़ल्ट-कमिट नियम, कैंसलेशन रणनीति, कैश और फ्रेशनेस पॉलिसी, लोडिंग और एरर स्टेट्स, एक्सेसिबल फीडबैक और वेरिफिकेशन प्लान डिज़ाइन करें। केवल "debounce जोड़ें" कहने के बजाय यह बताएं कि दिखाई देने वाला परिणाम किस क्वेरी को दर्शाता है।
यह सीनियर फ़्रंटएंड, React, और UI-इन्फ्रास्ट्रक्चर इंटरव्यू के लिए उपयुक्त है। React का आधिकारिक दस्तावेज़ डेटा-फ़ेचिंग रेस कंडीशन (race condition) को समझाने के लिए तेज़ टाइपिंग का उपयोग करता है और Effect क्लीनअप के दौरान पुराने रिस्पॉन्स को अनदेखा करने की सलाह देता है। MDN यह दस्तावेज़ित करता है कि AbortController.abort() फ़ेच, रिस्पॉन्स-बॉडी कंजम्पशन, या स्ट्रीम को समाप्त कर सकता है। web.dev का stale-while-revalidate मार्गदर्शन किसी स्वीकार्य पुराने मान को रिफ्रेश करते समय प्रदर्शित करने का कैश ट्रेड-ऑफ़ जोड़ता है। ये स्रोत विषय की तकनीकी प्रासंगिकता का समर्थन करते हैं, लेकिन किसी कंपनी के निश्चित प्रश्न या इंटरव्यू आवृत्ति को स्थापित नहीं करते हैं। यह श्रेणी frontend है क्योंकि मुख्य कौशल ब्राउज़र-साइड एसिंक्रोनस स्टेट, रेंडर निरंतरता (render consistency), और इंटरैक्शन फीडबैक है।
इंटरव्यूअर्स क्या मूल्यांकन करते हैं
पहला, क्या उम्मीदवार रिक्वेस्ट के पूरा होने और रिक्वेस्ट के अभी भी कमिट होने के योग्य होने के बीच अंतर कर सकता है? Promise का पहले पूरा होने का मतलब यह नहीं है कि यह वर्तमान क्वेरी का प्रतिनिधित्व करता है। प्रत्येक रिक्वेस्ट को एक स्थिर पहचान (identity) की आवश्यकता होती है, और वह पहचान या क्वेरी कुंजी कमिट के समय भी मेल खानी चाहिए।
दूसरा, क्या वे समझते हैं कि कैंसलेशन केवल रिसोर्स मैनेजमेंट है? AbortController व्यर्थ काम को कम कर सकता है, लेकिन सर्वर द्वारा रिक्वेस्ट प्रोसेस करने के बाद कैंसलेशन हो सकता है। अबॉर्ट (Abort) कोई व्यावसायिक रोलबैक (rollback) नहीं है और यह पुराने परिणाम से सुरक्षा का विकल्प नहीं बन सकता।
तीसरा, क्या वे पूरी स्टेट मशीन को मॉडल कर सकते हैं: खाली इनपुट, पहला लोड, मौजूदा परिणामों के साथ रिफ्रेश करना, सफलता, खाली परिणाम, पुनः प्रयास करने योग्य (retryable) एरर, पुराना कैश, और अनमाउंट—इन सभी के लिए स्पष्ट नियमों की आवश्यकता होती है। नई क्वेरी लोड करते समय पुराने परिणामों को बनाए रखना या स्केलेटन दिखाना क्वेरी सिमेंटिक्स और यूज़र को भ्रमित करने के जोखिम पर निर्भर करता है।
अंत में, क्या वे केवल सही क्रम में आने वाले सफल रिस्पॉन्स का परीक्षण करने के बजाय, रिस्पॉन्स क्रम को नियंत्रित करके और तेज़ टाइपिंग, क्लीयरिंग, पुनः प्रयास, कैश हिट, अनमाउंट और एक्सेसिबल घोषणाओं को कवर करके व्यवहार को सत्यापित कर सकते हैं?
पहले पूछने योग्य स्पष्टीकरण प्रश्न
- क्या प्रत्येक कीस्ट्रोक पर रिक्वेस्ट ट्रिगर होनी चाहिए? यदि उत्पाद यूज़र के रुकने की प्रतीक्षा करता है, तो debounce उपयोगी है, लेकिन यह केवल रिक्वेस्ट की संख्या कम करता है और पहले से भेजी गई रिक्वेस्ट्स के बीच रेस कंडीशन को हल नहीं करता है।
- क्या पुराने परिणाम दृश्यमान रह सकते हैं? सुझाव अक्सर रिफ्रेश के दौरान बने रह सकते हैं यदि उन्हें पिछली क्वेरी से संबंधित के रूप में लेबल किया गया हो; गलत चयन से बचने के लिए वित्तीय कोट्स या अनुमति परिणामों को साफ़ करने की आवश्यकता हो सकती है।
- कैश कुंजी को क्या अमान्य (invalidate) करता है? क्वेरी स्ट्रिंग, फ़िल्टर, भाषा, अकाउंट स्कोप, और डेटा वर्ज़न—ये सभी मायने रख सकते हैं। केवल पेज URL द्वारा कैशिंग करने से अलग-अलग अनुमतियां या फ़िल्टर मिक्स हो सकते हैं।
- क्या सर्वर कैंसलेशन या डुप्लीकेशन हटाने (deduplication) का समर्थन करता है? क्लाइंट को अभी भी शुद्धता (correctness) के लिए गार्ड्स की आवश्यकता होती है; सर्वर कैंसलेशन रिसोर्स के उपयोग में सुधार करता है लेकिन यह साबित नहीं कर सकता कि पुरानी रिक्वेस्ट का कोई प्रभाव नहीं पड़ा।
- क्या इनपुट को स्क्रीन-रीडर के लिए लाइव फीडबैक की आवश्यकता है? परिणाम संख्या या लोडिंग स्टेट्स विनम्रतापूर्वक (politely) मौजूदा
statusक्षेत्र का उपयोग कर सकते हैं, लेकिन प्रत्येक वर्ण (character) पर यूज़र को बाधित नहीं किया जाना चाहिए।
30-सेकंड उत्तर का ढांचा
"मैं प्रत्येक क्वेरी को एक रिक्वेस्ट की (request key) से दर्शाता हूँ और किसी रिस्पॉन्स को परिणामों को तभी अपडेट करने देता हूँ जब वह की अभी भी वर्तमान क्वेरी के बराबर हो। क्लीनअप पर, मैं नेटवर्क और बॉडी-रीडिंग के काम को मुक्त करने के लिए AbortController.abort() को कॉल करता हूँ, लेकिन मैं कैंसलेशन को रोलबैक नहीं मानता; भले ही अबॉर्ट विफल हो जाए, पहचान जांच (identity check) पुराने रिस्पॉन्स को छोड़ देती है। यूज़र के रुकने के बाद डिबाउंसिंग शोर को कम करती है लेकिन रेस प्रोटेक्शन की जगह नहीं लेती। स्टेट मशीन खाली, लोडिंग, पुराने परिणामों को रिफ्रेश करना, सफलता, खाली परिणाम, और पुनः प्रयास योग्य एरर के बीच अंतर करती है। कैश पूरी क्वेरी की और एक स्पष्ट फ्रेशनेस विंडो का उपयोग करता है। परीक्षण एक पुरानी रिक्वेस्ट को नई रिक्वेस्ट के बाद लौटने के लिए बाध्य करते हैं और इनपुट क्लीयरिंग, अनमाउंटिंग, पुनः प्रयास, कैशिंग और स्क्रीन-रीडर फीडबैक को कवर करते हैं।"
गहन उत्तर
1. एक रिज़ल्ट-कमिट इनवेरिएंट परिभाषित करें
currentKey, status, visibleData, और एक वैकल्पिक कैश बनाए रखें। currentKey में सामान्यीकृत (normalized) क्वेरी और परिणाम बदलने वाला प्रत्येक फ़िल्टर, भाषा, और अकाउंट स्कोप शामिल होता है। प्रत्येक नेटवर्क रिक्वेस्ट को एक अनूठा requestId मिलता है; इसका क्लोज़र इसकी कुंजी और कंट्रोलर को बनाए रखता है।
परिणाम कमिट करने से पहले, जांचें कि रिक्वेस्ट अमान्य नहीं हुई है और इसकी कुंजी अभी भी वर्तमान कुंजी के बराबर है। केवल तभी यह दृश्यमान डेटा, एरर, या सफलता की स्थिति लिख सकता है। यह इनवेरिएंट यह मानने से अधिक सुरक्षित है कि "अंतिम रिक्वेस्ट आमतौर पर अंत में समाप्त होती है," क्योंकि नेटवर्क इस प्रकार के क्रम की कोई गारंटी नहीं देता है।
UI को वर्तमान क्वेरी कुंजी, नवीनतम उपयोगी कैश प्रविष्टि, सक्रिय रिक्वेस्ट्स और एरर्स के शुद्ध प्रोजेक्शन के रूप में मानें। स्वतंत्र loading, data, और error मानों को सिंक्रनाइज़ करने वाले कई Effects से बचें; अन्यथा किसी क्वेरी को साफ़ करने या तेज़ी से बदलने से नई स्थिति में पुरानी एरर लिखी जा सकती है।
2. डिबाउंस, थ्रॉटल और रेस प्रोटेक्शन को अलग करें
डिबाउंस तेज़ इनपुट को एक रिक्वेस्ट में जोड़ता है और सुझावों के लिए उपयोगी है। थ्रॉटल एक निश्चित समय सीमा में रिक्वेस्ट्स को सीमित करता है और स्क्रॉलिंग या मॉनिटरिंग के लिए उपयोगी है। दोनों यह नियंत्रित करते हैं कि रिक्वेस्ट कब शुरू होती है; दोनों में से कोई भी पहले से भेजी गई रिक्वेस्ट को देर से आने से नहीं रोकता है।
250-मिलीसेकंड के डिबाउंस के बावजूद, जब कोई रिक्वेस्ट प्रक्रिया में हो तो यूज़र दोबारा टाइप कर सकता है। पहचान जांच (identity check) बनाए रखें। React का आधिकारिक उदाहरण Effect क्लीनअप में एक ignore फ़्लैग सेट करता है ताकि पुराना रिस्पॉन्स अब setResults को कॉल न करे; एक बढ़ता हुआ क्रम (sequence), क्वेरी-कुंजी तुलना, या स्पष्ट स्टेट मशीन उसी नियम को लागू करती है।
3. कैंसलेशन को ऑप्टिमाइज़ेशन मानें, शुद्धता का प्रमाण नहीं
प्रत्येक सक्रिय रिक्वेस्ट को उसका अपना AbortController दें। जब क्वेरी बदलती है, इनपुट साफ़ होता है, कंपोनेंट अनमाउंट होता है, या कोई प्रतिस्थापन (replacement) रिक्वेस्ट शुरू होती है, तो abort() को कॉल करें। AbortError को अपेक्षित कैंसलेशन के रूप में संभालें: इसे नेटवर्क विफलता के रूप में न दिखाएं और इसे नई क्वेरी की स्थिति को ओवरराइट न करने दें।
यह सिग्नल सर्वर प्रोसेसिंग को रोकने के लिए बहुत देर से पहुंच सकता है या केवल ब्राउज़र-साइड रीडिंग को रोक सकता है। "पुरानी रिक्वेस्ट रद्द करें" और "पुरानी रिक्वेस्ट का सर्वर-साइड पर कोई प्रभाव नहीं पड़ा" दो अलग-अलग दावे हैं। सर्च GETs में आम तौर पर कोई राइट साइड-इफेक्ट नहीं होता है, लेकिन फिर भी उन्हें requestId गार्ड की आवश्यकता होती है; एक अपरिवर्तनीय ऑपरेशन के लिए एक स्पष्ट आइडेम्पोटेंसी अनुबंध (idempotency contract) की आवश्यकता होती है।
4. पुराने परिणामों, स्केलेटन और कैश के बीच चयन करें
पहली क्वेरी पर डेटा न होने पर, एक लोडिंग प्लेसहोल्डर और एक्सेसिबल स्टेटस टेक्स्ट दिखाएं। रिफ्रेश के दौरान, यदि पुराने परिणाम सुरक्षित रहते हैं, तो उन्हें बनाए रखें, उस क्वेरी को लेबल करें जिससे वे संबंधित हैं, और एक हल्का रिफ्रेश इंडिकेटर दिखाएं। यदि पुराने डेटा से गलत चयन का जोखिम हो सकता है, तो इसे साफ़ करें या इसे गैर-कार्रवाई योग्य (non-actionable) बनाएं।
कैश कुंजी में संपूर्ण क्वेरी इनपुट शामिल होना चाहिए। कैश हिट तुरंत रेंडर हो सकता है और फिर बैकग्राउंड में पुन: मान्य (revalidate) हो सकता है, लेकिन इसका समय, स्रोत और एरर रिकॉर्ड करें ताकि पुराना या अनुमति-परिवर्तित डेटा वर्तमान तथ्य के रूप में प्रस्तुत न हो। Stale-while-revalidate पहले एक स्वीकार्य पुराने मान को प्रस्तुत करता है और एसिंक्रोनस रूप से एक नया मान प्राप्त करता है; उत्पाद को स्वीकार्य फ्रेशनेस विंडो को परिभाषित करना होगा।
5. एरर, खाली परिणाम और पुनः प्रयास (retries) संभालें
खाली परिणाम एक सफल स्थिति है, कोई नेटवर्क एरर नहीं। किसी एरर को उसकी वर्तमान कुंजी से बाँधें; पुरानी क्वेरी से आने वाली एरर को छोड़ दिया जाता है। पुनः प्रयास करने योग्य एरर क्वेरी और बैकऑफ़ जानकारी को बनाए रखती है। पुनः प्रयास (retry) पहले से ही पुरानी चिह्नित की गई Promise का पुनः उपयोग करने के बजाय एक नया requestId बनाता है।
यदि सर्वर 401, परिवर्तित अनुमति स्कोप, या अमान्य क्वेरी स्थितियां लौटाता है, तो हमेशा के लिए पुनः प्रयास करने के बजाय कैश को साफ़ या पुन: मान्य करें। नेटवर्क रिकवरी पर, केवल वर्तमान कुंजी के लिए रिक्वेस्ट करें ताकि कोई रिकवरी इवेंट उस क्वेरी को फिर से न भर दे जिसे यूज़र पहले ही साफ़ कर चुका है।
6. कीबोर्ड और सहायक तकनीक (assistive-technology) फीडबैक सुरक्षित रखें
परिणाम रिफ्रेश होने पर इनपुट फ़ोकस को स्थानांतरित न करें। स्थिर सूची पहचान (stable list identities) का उपयोग करें ताकि पुराने परिणामों को हटाने से स्क्रीन रीडर को पूरी सूची दोबारा न पढ़नी पड़े। लोडिंग, परिणाम संख्या और एरर्स को पहले से मौजूद विनम्र (polite) status क्षेत्र में रखें, और इसे केवल सार्थक स्थिति परिवर्तनों के लिए अपडेट करें।
कीबोर्ड उपयोगकर्ताओं को लोडिंग के दौरान टाइप करना जारी रखने, रद्द करने या परिणाम चुनने में सक्षम होना चाहिए। यदि कोई परिणाम पुराना है, तो चयन लागू करने से पहले पुष्टि करें कि उसकी क्वेरी कुंजी अभी भी मेल खाती है। रंग ही एकमात्र लोडिंग या एरर संकेत नहीं हो सकता; एरर टेक्स्ट को इनपुट या सूची से संबद्ध करें।
7. नियंत्रित क्रम के साथ स्टेट मशीन का परीक्षण करें
ट्रांसपोर्ट टेस्ट डबल को प्रत्येक रिक्वेस्ट को रोकना चाहिए और रिस्पॉन्स को मैन्युअल रूप से रिलीज़ करना चाहिए। एक नई रिक्वेस्ट के बाद पुरानी रिक्वेस्ट के सफल होने, नई सफलता के बाद पुरानी विफलता आने, क्लीयर करने के बाद पुराने रिस्पॉन्स आने, कैश हिट के बाद बैकग्राउंड रिफ्रेश विफल होने, अनमाउंट के बाद रिस्पॉन्स आने, AbortError, और पुनः प्रयास के दौरान दोबारा टाइप करने के परिदृश्यों को कवर करें।
प्रत्येक इवेंट के बाद वर्तमान कुंजी, दृश्यमान परिणाम, स्थिति, कैश टाइमस्टैम्प और घोषणा का सत्यापन (assert) करें। सत्यापित करें कि विभिन्न क्रमों में आने वाले समान पेलोड डुप्लिकेट रेंडरिंग या फ़ोकस के नुकसान का कारण नहीं बनते हैं। रिक्वेस्ट संख्या, कैंसलेशन दर, छोड़े गए पुराने रिस्पॉन्स, दृश्यमान-परिणाम विलंबता और पुनः प्रयास दर को ट्रैक करें, लेकिन गलत परिणामों को छिपाने के लिए कम रिक्वेस्ट्स का उपयोग न करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं सबसे पहले पूरी क्वेरी को टेक्स्ट, फ़िल्टर, भाषा और अनुमति स्कोप वाली कुंजी में सामान्यीकृत करता हूँ। प्रत्येक वास्तविक रिक्वेस्ट को एक requestId और AbortController मिलता है, और यह वर्तमान कुंजी को रिकॉर्ड करता है। किसी रिस्पॉन्स को सफलता, खाली परिणाम, या एरर कमिट करने से पहले दोनों जांच पास करनी होंगी—उसका requestId अभी भी सक्रिय है और उसकी कुंजी अभी भी मेल खाती है। इनपुट बदलने पर मैं पुराने कंट्रोलर को अबॉर्ट करता हूँ और AbortError को चुपचाप संभालता हूँ, लेकिन मैं यह दावा नहीं करता कि अबॉर्ट ने सर्वर प्रोसेसिंग को रोलबैक कर दिया है।
मैं शोर को कम करने के लिए 250-मिलीसेकंड के ठहराव के बाद रिक्वेस्ट भेजता हूँ। पहला लोड एक प्लेसहोल्डर दिखाता है। रिफ्रेश के दौरान मैं पुराने परिणामों को केवल तभी रखता हूँ जब वे सुरक्षित हों, उन्हें पिछली क्वेरी से संबंधित के रूप में लेबल करता हूँ, और अन्यथा उन्हें साफ़ कर देता हूँ। कैश प्रविष्टियां पूरी कुंजी का उपयोग करती हैं और बैकग्राउंड सत्यापन से पहले संक्षेप में रेंडर हो सकती हैं; फ्रेशनेस विंडो से बाहर की प्रविष्टि केवल लोडिंग दिखाती है।
स्टेट मशीन खाली इनपुट, लोडिंग, पुराने डेटा को रिफ्रेश करना, सफलता, खाली परिणाम, और पुनः प्रयास योग्य एरर के बीच अंतर करती है। एरर्स कुंजी से बंधी होती हैं, इसलिए देर से आने वाली पुरानी एरर को छोड़ दिया जाता है। फ़ोकस इनपुट में रहता है, परिणाम पहचान स्थिर रहती है, और पहले से मौजूद polite क्षेत्र प्रत्येक वर्ण के बजाय सार्थक स्थिति परिवर्तनों की घोषणा करता है।
इसके बाद मैं hell को hello के बाद लौटने के लिए बाध्य करता हूँ, क्लीयर करने के बाद पुराना रिस्पॉन्स डिलीवर करता हूँ, कैंसलेशन को विफल करता हूँ, कैश रिफ्रेश को विफल करता हूँ, अनमाउंट के बाद डिलीवर करता हूँ, और पुनः प्रयास के दौरान फिर से टाइप करता हूँ। अंतिम UI केवल वर्तमान कुंजी द्वारा व्याख्या योग्य होना चाहिए।"
सामान्य गलतियाँ
- केवल डिबाउंस करना → पहले से भेजी गई रिक्वेस्ट्स में अभी भी रेस हो सकती है → एक requestId या कुंजी सुरक्षा बनाए रखें।
- पूरा होने वाला अंतिम रिस्पॉन्स दिखाना → नेटवर्क पूरा होने का क्रम क्वेरी का क्रम नहीं है → केवल वर्तमान कुंजी ही कमिट कर सकती है।
- अबॉर्ट को रोलबैक मानना → सर्वर इसे पहले ही संसाधित कर चुका हो सकता है → क्लीनअप के लिए कैंसलेशन और शुद्धता के लिए पहचान/वर्ज़न नियमों का उपयोग करें।
- प्रत्येक क्वेरी के लिए एक ही कैश प्रविष्टि → परिणाम भर में फ़िल्टर, भाषाएं, या स्कोप लीक हो सकते हैं → कुंजी में प्रत्येक परिणाम इनपुट को शामिल करें।
- पुरानी एरर को नई क्वेरी को ओवरराइट करने देना → यूज़र्स को एक अप्रचलित विफलता दिखाई देती है → एरर्स को requestId और कुंजी से बाँधें।
- प्रत्येक लोड के लिए UI को खाली करना → यूज़र्स उपयोगी संदर्भ खो देते हैं → भ्रामक-डेटा जोखिम के आधार पर पुराने परिणाम या स्केलेटन चुनें।
- प्रत्येक कीस्ट्रोक की घोषणा करना → स्क्रीन रीडर बार-बार बाधित होते हैं → सार्थक लोडिंग, परिणाम और एरर परिवर्तनों की घोषणा करें।
- केवल क्रमित सफलता का परीक्षण करना → वास्तविक रेस कंडीशन अनुपस्थित रहती हैं → रिस्पॉन्स, कैंसल, क्लीयर, अनमाउंट, और पुनः प्रयास क्रम को नियंत्रित करें।
फ़ॉलो-अप प्रश्न और उत्तर
क्या पेजिनेशन या इनफ़ाइनाइट स्क्रॉलिंग के लिए एक कुंजी पर्याप्त है?
रिक्वेस्ट कुंजी में फ़िल्टर, सॉर्ट, कर्सर या पेज शामिल करें और प्रत्येक पेज को एक क्वेरी वर्ज़न से बाँधें। एक नई क्वेरी पुराने पेजों को हटा देती है। उसी क्वेरी के लिए दूसरा पेज लोड करने पर पिछला पेज दिखाई दे सकता है, लेकिन डुप्लिकेट कर्सर और पुराने पेज पुष्ट सूची को ओवरराइट नहीं कर सकते। क्लाइंट पेज नंबर से क्रम का अनुमान लगाने के बजाय सर्वर द्वारा दिए गए अगले कर्सर का उपयोग करें।
जब यूज़र ऑफ़लाइन टाइप करता है और फिर से कनेक्ट होता है तो क्या बदलता है?
सर्च को आम तौर पर प्रत्येक पुरानी रिक्वेस्ट को बनाए रखने की आवश्यकता नहीं होती है; वर्तमान इनपुट और अंतिम स्वीकार्य कैश रखें। पुनः कनेक्ट होने पर, केवल वर्तमान कुंजी के लिए रिक्वेस्ट करें और पुराने ऑफ़लाइन काम को अनदेखा करें। यदि ऑफ़लाइन सुझाव एक उत्पाद आवश्यकता है, तो कैश आयु, डेटा स्कोप, और फ्रेशनेस दिखाई देनी चाहिए ताकि ऑफ़लाइन परिणामों को रीयल-टाइम के रूप में प्रस्तुत न किया जाए।
क्या React Query या SWR इसे अकेले हल कर सकते हैं?
एक कैश लाइब्रेरी डिडुप्लीकेशन, कैशिंग, इनवैलिडेशन और लाइफसाइकिल प्रबंधन प्रदान कर सकती है, लेकिन उत्पाद अभी भी क्वेरी कुंजी, स्वीकार्य पुरानापन (staleness), पुनः प्रयास और इंटरैक्शन स्टेट्स को परिभाषित करता है। लाइब्रेरी कैंसलेशन या डिफ़ॉल्ट stale समय अनुमति स्कोप, भ्रामक-डेटा जोखिम, या एक्सेसिबल फीडबैक का निर्णय नहीं ले सकता है। लाइब्रेरी के रेस सिमेंटिक्स को सत्यापित करें और क्वेरी कुंजी तथा UI स्थिति में नियमों को एनकोड करें।
यदि सर्च ऑडिट लॉगिंग के साथ POST बन जाता है तो क्या कैंसलेशन सुरक्षित है?
यह मान न लें कि यह सुरक्षित है। एक POST के सर्वर-साइड प्रभाव हो सकते हैं, और क्लाइंट अबॉर्ट किसी ट्रांजेक्शन को रोलबैक नहीं करता है। एक आइडेम्पोटेंसी कुंजी, एक स्पष्ट सबमिशन स्थिति, और एक स्थिति-क्वेरी एंडपॉइंट का उपयोग करें; आधिकारिक पुष्टि के बाद ही सफलता दिखाएं। एक जटिल दुष्प्रभाव-रहित (side-effect-free) क्वेरी के लिए POST अभी भी उचित है, लेकिन इसका पुनः प्रयास और कैंसलेशन अनुबंध स्पष्ट होना चाहिए।