कतार

Question

के साथ लंबे समय से चल रहे आरईएसटी एपीआई हम एक आरईएसटी एपीआई लागू कर रहे हैं, जो कई लंबे समय तक चलने वाले बैकएंड कार्यों को बंद कर देगा। मैं रीस्टफुल वेब सर्विसेज कुकबुक पढ़ रहा हूं और अनुशंसा की जा रही कार्य को इंगित करने वाली सामग्री-स्थान शीर्षलेख के साथ स्वीकृत HTTP 202/स्वीकृति देना है। (उदा। http://www.example.org/orders/tasks/1234), और क्लाइंट लंबे समय तक चल रहे कार्य पर अपडेट के लिए इस यूआरआई को मतदान करता है।

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

REST API तुरंत एक कतार में पदों, तो यह एक GUID पैदा करते हैं और देते हैं के रूप में संदेश पर एक विशेषता कतार में जोड़ा जा रहा है, लेकिन अनुरोध की स्थिति प्राप्त करने में कठिनाई अजीब हो जाता है कि सकता है।

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

किसी भी तरह डेटाबेस डेटाबेस को पहले जोड़ना, फिर कतार में संदेश जोड़ना पीछे की ओर लगता है, लेकिन केवल कतार में अनुरोध जोड़ने से प्रगति को ट्रैक करना मुश्किल हो जाता है।

अनुशंसित दृष्टिकोण क्या होगा?

आपकी अंतर्दृष्टि के लिए बहुत बहुत धन्यवाद।

Answer 1

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

आपकी समस्या यह है कि आपके लंबे समय तक चलने वाले क्लाइंट कनेक्शन टाइमआउट्स, इसलिए आप कोई प्रतिक्रिया नहीं भेज सकते हैं। तो आप कमान में आदेश डालकर एक मतदान लिंक जोड़ने के बाद 202 स्वीकार कर सकते हैं, इसलिए ग्राहक परिवर्तनों के लिए मतदान कर पाएंगे। आपके कार्यों में एकाधिक उप-कार्य हैं इसलिए प्रगति है, न केवल लंबित और पूर्ण स्थिति में परिवर्तन।

1. यदि आप मतदान के साथ रहना चाहते हैं, तो आपको एक नया आरईएसटी संसाधन बनाना चाहिए, जिसमें वास्तविक स्थिति और लंबे समय तक चलने वाले कार्य की प्रगति होनी चाहिए। इसका मतलब है कि आपको इस जानकारी को डेटाबेस में संग्रहीत करना है, इसलिए आरईएसटी सेवा GET /tasks/23461/status जैसे अनुरोधों का जवाब दे पाएगी। इसका अर्थ यह है कि जब आपके उप-कार्य या पूरे कार्य को पूरा किया जाता है तो आपके कार्यकर्ता को डेटाबेस को अद्यतन करना होता है।
2. यदि आपकी आरईएसटी सेवा एक डेमॉन के रूप में चल रही है, तो आप इसे प्रगति से सूचित कर सकते हैं, इसलिए डेटाबेस में कार्य की स्थिति को संग्रहीत करना कार्यकर्ता की ज़िम्मेदारी नहीं होगी। इस तरह की आरईएसटी सेवा भी स्मृति में जानकारी स्टोर कर सकते हैं।
3. यदि आप क्लाइंट को सूचित करने के लिए websockets का उपयोग करने का निर्णय लेते हैं, तो आप एक अधिसूचना सेवा बना सकते हैं। आरईएसटी द्वारा आपको एक कार्य आईडी के साथ जवाब देना होगा। इसके बाद आप वेबस्कैस कनेक्शन पर यह कार्य आईडी वापस भेज दें, इसलिए अधिसूचना सेवा को पता चलेगा कि कौन सा वेबसाइकिल कनेक्शन किसी निश्चित कार्य की घटनाओं के लिए सदस्यता लेता है। इसके बाद आपको आरईएसटी सेवा की आवश्यकता नहीं होगी, जब तक कि ग्राहक कनेक्शन बंद नहीं करता है तब तक आप वेबस्केट कनेक्शन के माध्यम से प्रगति भेज सकते हैं।
4. आप इन समाधानों को निम्न तरीके से जोड़ सकते हैं। आप अपनी आरईएसटी सेवा को कार्य संसाधन बनाने के लिए देते हैं, ताकि आप मतदान लिंक का उपयोग करके प्रगति तक पहुंच सकें। उसके बाद आप 202 के साथ एक पहचानकर्ता वापस भेजते हैं जिसे आप वेबसाइकिल कनेक्शन के माध्यम से वापस भेजते हैं। तो आप ग्राहक को सूचित करने के लिए एक अधिसूचना सेवा का उपयोग कर सकते हैं। प्रगति से आपका कर्मचारी आरईएसटी सेवा को सूचित करेगा, जो GET /tasks/23461/status जैसे लिंक बनाएगा और अधिसूचना सेवा के माध्यम से क्लाइंट को वह लिंक भेज देगा। इसके बाद ग्राहक अपनी स्थिति अपडेट करने के लिए लिंक का उपयोग कर सकता है।

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