क्या यह निर्धारित करने का एक शानदार तरीका है कि कोई पोस्ट सफल होगा या नहीं?

Question

क्या यह निर्धारित करने का एक शानदार तरीका है कि कोई पोस्ट (या कोई अन्य गैर-बेवकूफ क्रिया) सफल होगा या नहीं? यह उन मामलों में उपयोगी प्रतीत होता है जहां आपको अनिवार्य रूप से विभिन्न सेवाओं के खिलाफ कई बेवकूफ अनुरोध करने की आवश्यकता होती है, जिनमें से कोई भी असफल हो सकता है। यह अच्छा होगा अगर इन अनुरोधों को "लेनदेन" (यानी रोलबैक के लिए समर्थन के साथ) में किया जा सकता है, लेकिन चूंकि यह असंभव है, तो यह जांचना है कि प्रत्येक अनुरोध वास्तव में उन्हें करने से पहले सफल होगा या नहीं।

उदाहरण के लिए मान लीजिए कि मैं एक ईकॉमर्स सिस्टम बना रहा हूं जो लोगों को उन पर मुद्रित कस्टम टेक्स्ट के साथ टी-शर्ट खरीदने की अनुमति देता है, और इस प्रणाली को दो अलग-अलग सेवाओं के साथ एकीकृत करने की आवश्यकता है: एक टी-शर्ट प्रिंटिंग सेवा, और एक भुगतान सेवा । इनमें से प्रत्येक में एक विश्वसनीय API है, और या तो असफल हो सकता है। (उदाहरण के लिए प्रिंटिंग कंपनी टी-शर्ट पर कुछ शब्दों को मुद्रित करने से इनकार कर सकती है, और क्रेडिट कार्ड की समयसीमा समाप्त होने पर बैंक शिकायत कर सकता है।) क्या इन दो अनुरोधों को अनुमानित रूप से करने का कोई तरीका है, इसलिए मेरा सिस्टम केवल आगे बढ़ेगा अगर दोनों अनुरोध मान्य दिखाई देते हैं?

यदि नहीं, तो क्या इस समस्या को अलग तरीके से हल किया जा सकता है? POST के माध्यम से status = pending के साथ संसाधन बनाना, और इसे सभी status = complete पर बदलना यदि सभी अनुरोध सफल होते हैं? (DELETE अधिक मुश्किल है ...)

Answer 1

HTTP वास्तव में अपने परिदृश्य के लिए 202 स्थिति कोड को परिभाषित करता है:

202 स्वीकृत

अनुरोध प्रक्रिया के लिए स्वीकार किया गया है, लेकिन प्रक्रिया पूरी नहीं हुई है। अनुरोध पर अंततः कार्य किया जा सकता है या नहीं, क्योंकि वास्तव में प्रसंस्करण होने पर इसे अस्वीकृत किया जा सकता है। इस तरह के एसिंक्रोनस ऑपरेशन से स्टेटस कोड दोबारा भेजने की कोई सुविधा नहीं है।

202 प्रतिक्रिया जानबूझकर गैर-कमजोर है। इसका उद्देश्य किसी सर्वर को किसी अन्य प्रक्रिया के लिए अनुरोध स्वीकार करने की अनुमति देना है (शायद बैच-उन्मुख प्रक्रिया जो केवल प्रति दिन एक बार चलती है) बिना किसी प्रक्रिया के सर्वर की कनेक्शन तब तक जारी रहती है जब तक प्रक्रिया पूरी नहीं हो जाती। इस प्रतिक्रिया के साथ लौटाई गई इकाई में अनुरोध की वर्तमान स्थिति का संकेत होना चाहिए और या तो स्थिति मॉनिटर के लिए सूचक या कुछ अनुमान जब उपयोगकर्ता अनुरोध पूरा होने की उम्मीद कर सकता है।

स्रोत: HTTP 1.1 Status Code Definition

यह 201 निर्मित के समान है, सिवाय इसके कि आप संकेत कर रहे हैं कि अनुरोध पूर्ण नहीं किया गया है और संस्था अभी तक नहीं बनाया गया है। आपकी प्रतिक्रिया में "आदेश अनुरोध" का प्रतिनिधित्व करने वाले संसाधन के लिए एक यूआरएल होगा, इसलिए ग्राहक इस यूआरएल के माध्यम से आदेश की स्थिति की जांच कर सकते हैं।

---

अधिक सीधे आपके सवाल का जवाब करने के लिए: कोई तरीका नहीं है करने के लिए "परीक्षण" है कि क्या एक अनुरोध इससे पहले कि आप यह कर, क्योंकि आप पेशनीगोई के लिए पूछ रहे हैं सफल होगा।

तकनीकी समस्याओं की सीमा को पूर्ववत करना संभव नहीं है जो भविष्य में अनुरोध करने का प्रयास करते समय हो सकता है। नेटवर्क अनुपलब्ध हो सकता है, सर्वर अपने डेटाबेस या बाहरी सिस्टम तक पहुंचने में सक्षम नहीं हो सकता है, यह कार्य करने के लिए निर्भर करता है, वहां एक पावर-कट हो सकता है और सर्वर ऑफ़लाइन है, एक भटक न्यूट्रिनो आपकी स्मृति में भटक सकता है और 0 को टक्कर दे सकता है 1 को एक विनाशकारी कर्नेल गलती का कारण बनता है।

रिमोट सेवा का उपभोग करने के लिए आपको किसी अन्य प्रक्रिया के अलगाव में किसी भी अनुरोध की संभावित विफलताओं के लिए खाते की आवश्यकता है।

आपकी विशिष्ट समस्या के लिए, यदि सेवाओं में कोई लेनदेन सुरक्षा नहीं है, तो आप वहां कोई भी सेंकना नहीं कर सकते हैं और आपको इसे और अधिक वास्तविक दुनिया में सौदा करना होगा। मेरे सिर के ऊपर से कुछ विकल्प:

1. , आप एक "परीक्षण" तंत्र देने के लिए ताकि आप देख सकते हैं कि वे वास्तव में रखकर बिना किसी भी आदेश की प्रक्रिया शुरू करेंगे टी-शर्ट कंपनी प्राप्त करें। यह हो सकता है कि उनके साथ एक ऑर्डर देना एक दो चरण का ऑपरेशन है, जहां आप पहले चरण में ऑर्डर बनाते हैं (जिस समय वे अपनी सृजन को मान्य करते हैं) और फिर आप बाद में संसाधित होने के आदेश मांगते हैं (भुगतान करने के बाद सफलतापूर्वक)।

2. पहले क्रेडिट कार्ड भुगतान लें और अपना ऑर्डर "भुगतान" स्थिति में ले जाएं। फिर टी-शर्ट सेवा के साथ एक एसिंक्रोनस प्रक्रिया के रूप में आदेश को पूरा करने का प्रयास करें। अगर पूर्ति विफल हो जाती है और आप यह पहचान सकते हैं कि ग्राहक ने कुछ मुद्रित करने की कोशिश की है, तो कंपनी उत्पादन के लिए तैयार नहीं है, तो आपको उनके आदेश को बदलने या धनवापसी का उत्पादन करने के लिए उनसे संपर्क करना होगा।

अधिकांश संगठन अपनी तकनीकी सादगी और व्यापार को कम जोखिम के कारण दूसरे दृष्टिकोण को अपनाएंगे। यह टी-शर्ट सेवा से निपटने में सक्षम होने का लाभ भी नहीं है; एसिंक्रोनस प्रक्रिया बस तब तक प्रतीक्षा करती है जब तक सेवा उपलब्ध न हो और उस समय ऑर्डर पूरा न हो जाए।

Answer 2

बिल्कुल। ऐसा किया जा सकता है जैसा कि आप अपने अंतिम वाक्य में सुझाव देते हैं। विचार संसाधन निर्माण को रद्द करना होगा (जो नेटवर्क विफलताओं तक हमेशा काम करेगा) जो "ऑर्डर स्वीकृति" के "जारी अनुरोध" का प्रतिनिधित्व करता है, जिसे बाद में तय किया जा सकता है। चूंकि POST एक "स्थान" शीर्षलेख देता है, फिर आप किसी भी पल में अपने अनुरोध की "स्थिति" पुनर्प्राप्त कर सकते हैं।

किसी बिंदु पर यह या तो स्वीकार या अस्वीकार कर दिया जा सकता है। यह सहज हो सकता है या इसमें कुछ समय लग सकता है, इसलिए आपको इन प्रतिबंधों के साथ अपनी सेवा तैयार करनी होगी (यानी क्लाइंट को यह जांचने की इजाजत है कि उसका आदेश स्वीकार किया गया है या किसी प्रकार की प्रति घंटा/दैनिक सेवा जो स्वीकृत अनुरोध एकत्र करती है) ।