HTTP 202 स्वीकृत (HTTP / 1.1)
आप HTTP 202 Acceptedस्टेटस ढूंढ रहे हैं । RFC 2616 देखें :
प्रसंस्करण के लिए अनुरोध स्वीकार कर लिया गया है, लेकिन प्रसंस्करण पूरा नहीं हुआ है।
HTTP 102 प्रसंस्करण (WebDAV)
RFC 2518 उपयोग करने का सुझाव देता है HTTP 102 Processing:
102 (प्रसंस्करण) स्थिति कोड एक अंतरिम प्रतिक्रिया है जिसका उपयोग क्लाइंट को सूचित करने के लिए किया जाता है कि सर्वर ने पूरा अनुरोध स्वीकार कर लिया है, लेकिन अभी तक इसे पूरा नहीं किया है।
लेकिन यह एक चेतावनी है:
अनुरोध पूरा होने के बाद सर्वर को अंतिम प्रतिक्रिया भेजनी होगी।
मुझे यकीन नहीं है कि अंतिम वाक्य की व्याख्या कैसे करें। क्या प्रोसेसिंग के दौरान सर्वर को कुछ भी भेजने से बचना चाहिए और पूरा होने के बाद ही जवाब देना चाहिए ? या यह केवल प्रोसेसिंग समाप्त होने पर ही प्रतिक्रिया को समाप्त करने के लिए मजबूर करता है ? यदि आप प्रगति की रिपोर्ट करना चाहते हैं तो यह उपयोगी हो सकता है। HTTP 102 और फ्लश प्रतिक्रिया बाइट (या लाइन द्वारा लाइन) द्वारा बाइट भेजें।
उदाहरण के लिए, एक लंबी लेकिन रैखिक प्रक्रिया के लिए, आप प्रत्येक चरित्र के बाद फ्लशिंग एक सौ डॉट्स भेज सकते हैं। यदि क्लाइंट पक्ष (जैसे जावास्क्रिप्ट एप्लिकेशन) जानता है कि उसे ठीक 100 वर्णों की अपेक्षा करनी चाहिए, तो वह इसे उपयोगकर्ता को दिखाने के लिए प्रगति पट्टी के साथ मेल कर सकता है।
एक अन्य उदाहरण एक ऐसी प्रक्रिया की चिंता करता है जिसमें कई गैर-रेखीय चरण होते हैं। प्रत्येक चरण के बाद, आप एक लॉग संदेश को फ्लश कर सकते हैं जो अंततः उपयोगकर्ता को प्रदर्शित किया जाएगा, ताकि अंतिम उपयोगकर्ता को पता चल सके कि प्रक्रिया कैसे हो रही है।
प्रगतिशील फ्लशिंग के साथ मुद्दे
ध्यान दें कि जब इस तकनीक की अपनी खूबियाँ हैं, तो मैं इसकी सिफारिश नहीं करूँगा । कारणों में से एक यह है कि यह कनेक्शन को खुले रहने के लिए मजबूर करता है, जो सेवा की उपलब्धता के मामले में चोट पहुंचा सकता है और अच्छी तरह से स्केल नहीं करता है।
एक बेहतर तरीका यह है कि HTTP 202 Acceptedया तो जवाब देने के लिए या तो उपयोगकर्ता को बाद में आपको यह निर्धारित करने के लिए वापस जाने दें कि क्या प्रसंस्करण समाप्त हो गया है (उदाहरण के लिए किसी दिए गए यूआरआई को बार-बार कॉल /process/resultकरना जैसे कि HTTP 404 के साथ प्रतिक्रिया नहीं मिलेगी या HTTP 409 प्रक्रिया तक संघर्ष। फ़िनिश और परिणाम तैयार है), या उपयोगकर्ता को सूचित करें जब प्रसंस्करण किया जाता है यदि आप क्लाइंट को संदेश कतार सेवा ( उदाहरण ) या वेबस्केट के माध्यम से वापस कॉल करने में सक्षम हैं ।
व्यावहारिक उदाहरण
एक वेब सेवा की कल्पना करें जो वीडियो परिवर्तित करती है। प्रवेश बिंदु है:
POST /video/convert
जो HTTP अनुरोध से एक वीडियो फ़ाइल लेता है और इसके साथ कुछ जादू करता है। आइए कल्पना करें कि जादू सीपीयू-गहन है, इसलिए यह अनुरोध के हस्तांतरण के दौरान वास्तविक समय में नहीं किया जा सकता है। इसका मतलब है कि एक बार फ़ाइल स्थानांतरित हो जाने के बाद, सर्वर HTTP 202 Acceptedकुछ JSON सामग्री के साथ जवाब देगा , जिसका अर्थ है "हाँ, मुझे आपका वीडियो मिल गया है, और मैं इस पर काम कर रहा हूं; यह भविष्य में कहीं भी तैयार होगा और आईडी 123 के माध्यम से उपलब्ध होगा। "
क्लाइंट के पास प्रोसेसिंग खत्म होने पर अधिसूचित होने के लिए एक संदेश कतार की सदस्यता लेने की संभावना है। एक बार जब यह समाप्त हो जाता है, तो ग्राहक संसाधित वीडियो डाउनलोड कर सकता है:
GET /video/download/123
जो जाता है HTTP 200।
यदि ग्राहक अधिसूचना प्राप्त करने से पहले इस URI से पूछताछ करता है तो क्या होगा? खैर, सर्वर तब से जवाब देगा HTTP 404, वास्तव में, वीडियो अभी तक मौजूद नहीं है। यह वर्तमान में तैयार किया जा सकता है। यह कभी अनुरोध नहीं किया जा सकता है। यह अतीत में कुछ समय तक मौजूद रह सकता है और बाद में हटा दिया जा सकता है। यह सब मायने रखता है कि परिणामी वीडियो उपलब्ध नहीं है।
अब, क्या होगा अगर ग्राहक न केवल अंतिम वीडियो के बारे में परवाह करता है, बल्कि प्रगति के बारे में भी (जो संदेश कतार सेवा या किसी भी समान तंत्र नहीं है तो और भी महत्वपूर्ण होगा)?
इस स्थिति में, आप एक और समापन बिंदु का उपयोग कर सकते हैं:
GET /video/status/123
जो इस के समान प्रतिक्रिया देगा:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
बार-बार अनुरोध करने पर भी प्रगति दिखाई देगी:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
उन तीन प्रकार के अनुरोधों के बीच अंतर करना महत्वपूर्ण है:
POST /video/convertएक कार्य कतार में। इसे केवल एक बार कॉल किया जाना चाहिए: इसे फिर से कॉल करना एक अतिरिक्त कार्य को कतारबद्ध करेगा।GET /video/download/123ऑपरेशन के परिणाम की चिंता : संसाधन वीडियो है। प्रसंस्करण - जो हुड के तहत हुआ है वह अनुरोध से पहले वास्तविक परिणाम तैयार करने के लिए और स्वतंत्र रूप से अनुरोध करने के लिए - यहाँ अप्रासंगिक है। इसे एक बार या कई बार बुलाया जा सकता है।GET /video/status/123प्रसंस्करण प्रति से संबंधित है । यह कुछ भी कतार नहीं है। यह परिणामी वीडियो के बारे में परवाह नहीं करता है। संसाधन प्रसंस्करण ही है। इसे एक बार या कई बार बुलाया जा सकता है।