API के माध्यम से ऑर्डर जाँचते समय "प्रोसेसिंग" स्थिति को संभालना
API प्रतिक्रिया में processing का क्या अर्थ है
processing, in_progress या कोई अन्य समान स्थिति का अर्थ है कि आपूर्तिकर्ता ने ऑर्डर को कार्य में ले लिया है, लेकिन परिणाम दर्ज नहीं किया है। प्रचार सेवाओं के लिए यह लिंक की जाँच, कतार में प्रतीक्षा, कार्य का शुभारंभ या ऑर्डर किए गए वॉल्यूम की क्रमिक डिलीवरी हो सकती है।
Processing सफल निष्पादन की पुष्टि नहीं करता और न ही त्रुटि का अर्थ है। इसके बाद ऑर्डर completed, partial, canceled या failed में जा सकता है। जब तक आपूर्तिकर्ता मध्यवर्ती स्थिति लौटाता है, उसी लिंक और उसी वॉल्यूम के लिए दोबारा अनुरोध न बनाएँ।
processing स्थिति के साथ HTTP 200 का अर्थ है API की सफल प्रतिक्रिया, ऑर्डर का सफल समापन नहीं। इन घटनाओं को अलग से संग्रहीत और संभालना आवश्यक है।
ऑर्डर जाँचने के लिए कौन-सा डेटा आवश्यक है
Polling के लिए बाहरी ऑर्डर ID आवश्यक है, जो आपूर्तिकर्ता ने निर्माण के समय लौटाया था। इसे आंतरिक ID, मूल वॉल्यूम, सेवा पैरामीटर, लिंक, निर्माण समय और मूल API प्रतिक्रिया के साथ सहेजें। चैनल नाम, लिंक या वॉल्यूम से ऑर्डर खोजना विश्वसनीय नहीं है: ऐसे मान कई अनुरोधों में मेल खा सकते हैं।
यदि निर्माण के बाद टाइमआउट आया है, तो अनुरोध को स्वचालित रूप से दोबारा न भेजें। आपूर्तिकर्ता ने अनुरोध स्वीकार कर लिया हो सकता है, और प्रतिक्रिया रास्ते में खो सकती है। पहले ऑर्डर खोजने की विधि का उपयोग करें, यदि यह दस्तावेज़ में उपलब्ध हो, या मामले को जाँच के लिए भेजें।
केवल वर्तमान स्थिति संग्रहीत करने की कमी यह है कि विवाद के समय यह पुनर्स्थापित नहीं किया जा सकता कि ऑर्डर कब processing में गया, क्या प्रगति हुई थी और पहले कौन-सी प्रतिक्रियाएँ आई थीं।
curl के माध्यम से स्थिति अनुरोध का उदाहरण
सटीक पता, प्राधिकरण विधि और फ़ील्ड नाम आपूर्तिकर्ता के दस्तावेज़ से लें। नीचे एक टेम्पलेट दिखाया गया है: कोणीय कोष्ठक में मानों को विशिष्ट API के डेटा से बदलना आवश्यक है।
एक ऑर्डर के लिए GET अनुरोध
curl -X GET "https://
-H "Authorization: Bearer
-H "Accept: application/json"
प्रतिक्रिया का उदाहरण:
{
"order_id": "
"status": "processing",
"completed_quantity": 250,
"remains": 750,
"updated_at": "समय_मान"
}
completed_quantity और remains फ़ील्ड केवल संरचना के उदाहरण के रूप में दिए गए हैं। आपूर्तिकर्ता progress, start_count, balance या अन्य नामों का उपयोग कर सकता है। GET दृष्टिकोण की कमी यह है कि कुछ API स्थिति जाँच केवल POST के माध्यम से स्वीकार करते हैं।
POST अनुरोध और बैच जाँच का उदाहरण
एक ऑर्डर की स्थिति के लिए POST अनुरोध
curl -X POST "https://
-H "Authorization: Bearer
-H "Content-Type: application/json" \
-d '{"order_id":"
API कुंजी को URL स्ट्रिंग में न भेजें। अनुरोध पते प्रॉक्सी लॉग, एनालिटिक्स सिस्टम, ब्राउज़र इतिहास और तकनीकी लॉग में दर्ज हो जाते हैं। POST की कमी यह है कि इसे एड्रेस बार के माध्यम से मैन्युअल रूप से जाँचना कठिन है, लेकिन यह गोपनीय जानकारी को URL में स्थानांतरित करने का कारण नहीं है।
सक्रिय ऑर्डर का बैच अनुरोध
यदि API बैच जाँच का समर्थन करता है, तो कई ID एक अनुरोध में भेजें:
curl -X POST "https://
-H "Authorization: Bearer
-H "Content-Type: application/json" \
-d '{"order_ids":["
प्रतिक्रिया को सरणी में तत्व की स्थिति से नहीं, बल्कि बाहरी ID से आंतरिक ऑर्डर के साथ मिलाएँ। बैच जाँच की कमी: आपूर्तिकर्ता सभी ऑर्डर नहीं लौटा सकता, सूची का आकार सीमित कर सकता है या केवल एक ID के लिए त्रुटि बता सकता है।
processing के लिए polling कैसे निर्धारित करें
पहली processing प्रतिक्रिया के बाद अगली जाँच को कतार में रखें। अंतराल API दस्तावेज़, आवृत्ति सीमाओं और सेवा की प्रकृति के अनुसार चुनें। जिन कार्यों में स्थिति तेज़ी से बदलती है, उनके लिए शुरुआत में अधिक बार जाँच स्वीकार्य है। क्रमिक प्रचार के लिए लगातार छोटे अनुरोध आमतौर पर नई जानकारी नहीं देते।
व्यावहारिक योजना — समान processing प्रतिक्रियाओं के बाद विराम बढ़ाना। पहली जाँच प्रारंभिक देरी के बाद होती है, फिर अंतराल निर्धारित अधिकतम तक बढ़ता है। यदि API प्रगति या नया अपडेट समय लौटाता है, तो गणना उस परिवर्तन से शुरू की जा सकती है।
- ऑर्डर बनाने के बाद तुरंत कई बार लगातार स्थिति की जाँच न करें: सेवा को कतार में लगने में समय लग सकता है।
- बार-बार processing आने पर अनुरोधों के बीच अंतराल बढ़ाएँ, स्थिर आवृत्ति न रखें।
- कार्य शुरू करने के समय में थोड़ा यादृच्छिक विचलन जोड़ें, ताकि ऑर्डर एक साथ API को क्वेरी न करें।
- यदि आपूर्तिकर्ता Retry-After या समान सिफ़ारिश भेजता है, तो उसे प्राथमिकता के रूप में उपयोग करें।
- वेबहुक वाले ऑर्डर के लिए नियंत्रण polling रखें: सूचना नहीं पहुँच सकती।
दुर्लभ polling की कमी — वास्तविक समापन के बाद इंटरफ़ेस पुरानी स्थिति दिखा सकता है। बहुत बार polling की कमी — API सीमाओं से टकराने, 429 प्राप्त करने और अतिरिक्त भार बनाने का जोखिम।
processing नियंत्रण के लिए कौन-से समय संग्रहीत करें
सामान्य निष्पादन और अटकाव के बीच अंतर करने के लिए केवल वर्तमान स्थिति पर्याप्त नहीं है। प्रत्येक सक्रिय ऑर्डर के लिए निर्माण समय, पहली processing प्राप्ति, अंतिम सफल API प्रतिक्रिया, बाहरी स्थिति का अंतिम परिवर्तन और प्रगति का अंतिम परिवर्तन संग्रहीत करें।
मूल वॉल्यूम, पुष्टि किया गया निष्पादित वॉल्यूम, शेष और आपूर्तिकर्ता की मूल स्थिति सहेजना भी उपयोगी है। यदि API प्रगति नहीं देता, तो यह ऑर्डर को अटका हुआ मानने का कारण नहीं है: अंतिम प्रतिक्रिया के समय और अपेक्षित प्रसंस्करण अवधि पर ध्यान दें, यदि यह सेवा की शर्तों में निर्दिष्ट हो।
अधिकतम प्रतीक्षा समय सभी सेवाओं के लिए एक संख्या के रूप में निर्धारित नहीं किया जा सकता। आपूर्तिकर्ता द्वारा विशिष्ट सेवा के लिए बताई गई अवधि का उपयोग करें, कतार और डेटा अपडेट के लिए आंतरिक मार्जिन के साथ। यदि अवधि निर्दिष्ट नहीं है, तो प्रत्येक सेवा श्रेणी के लिए अलग नियम निर्धारित करें और वास्तविक प्रसंस्करण इतिहास के आधार पर उसकी समीक्षा करें।
यदि processing नहीं बदलता तो क्या करें
लंबा processing त्रुटि सिद्ध नहीं करता। पहले जाँचें कि क्या सफल API प्रतिक्रियाएँ आई थीं, क्या completed_quantity या remains बदले, क्या वेबहुक थे और क्या सेवा के नियम बदले। दृश्य वृद्धि का अभाव प्लेटफ़ॉर्म आँकड़ों की देरी या इससे संबंधित हो सकता है कि आपूर्तिकर्ता प्रगति केवल अंत में अपडेट करता है।
जब आंतरिक प्रतीक्षा अवधि पार हो जाए, तो ऑर्डर को स्वचालित रूप से रद्द न करें। असामयिक स्थिति जाँच करें, यदि प्रदान किया गया हो तो अलग विधि से डेटा का अनुरोध करें, और सूचना इतिहास की जाँच करें। यदि आपूर्तिकर्ता अभी भी processing की पुष्टि करता है, तो ऑर्डर को आंतरिक स्थिति "जाँच आवश्यक" में ले जाएँ, लेकिन बाहरी स्थिति को प्रतिस्थापित किए बिना सहेजें।
- अंतिम पुष्टि प्रतिक्रिया का समय और पूरी API प्रतिक्रिया दर्ज करें।
- जाँचें कि पिछले सर्वेक्षण के बाद से प्रगति बदली है या नहीं।
- आंतरिक सीमा तक पहुँचने के बाद स्वचालित अनुरोधों की आवृत्ति कम करें।
- सहायता को बाहरी ID, लिंक, सेवा पैरामीटर, स्थिति इतिहास और तकनीकी त्रुटियाँ भेजें।
- आपूर्तिकर्ता की प्रतिक्रिया या स्पष्ट अंतिम स्थिति से पहले शेष को दोबारा न चलाएँ।
मैन्युअल जाँच की कमी — ऑर्डर को सहायता का ध्यान चाहिए। लेकिन स्वचालित रद्दीकरण या डुप्लिकेट अधिक खतरनाक है: आपूर्तिकर्ता पर निष्पादन जारी रह सकता है।
अनुरोध विफलता को ऑर्डर स्थिति से कैसे अलग करें
नेटवर्क त्रुटि, टाइमआउट, HTTP 429 और 5xx प्रतिक्रिया ऑर्डर की स्थिति नहीं बताते। वे केवल यह दर्शाते हैं कि नई विश्वसनीय स्थिति प्राप्त नहीं हो सकी। ऐसी स्थिति में अंतिम पुष्टि स्थिति रखें, तकनीकी त्रुटि दर्ज करें और नई जाँच की योजना बनाएँ।
429 पर Retry-After का ध्यान रखें, यदि हेडर भेजा गया हो। अस्थायी नेटवर्क त्रुटियों और 5xx पर प्रयासों के बीच विराम बढ़ाएँ। प्राधिकरण, हस्ताक्षर या पहुँच अधिकारों में त्रुटि पर बार-बार पुनःप्रयास न करें: कुंजी, टोकन की वैधता अवधि, IP प्रतिबंध और पहुँच सेटिंग्स की जाँच आवश्यक है।
यदि API ने HTTP 200 लौटाया, लेकिन JSON पार्स नहीं होता या प्रतिक्रिया में order_id और status नहीं है, तो प्रतिक्रिया का पूरा बॉडी सहेजें और जाँच को गलत के रूप में चिह्नित करें। स्थिति की अनुपस्थिति को completed, canceled या processing से न बदलें।
स्वचालित पुनः अनुरोध कब बंद करें
Polling अनंत नहीं होना चाहिए। अस्थायी त्रुटियों के लिए तकनीकी पुनरावृत्तियों की संख्या सीमित करें और processing में ऑर्डर के कुल समय को अलग से नियंत्रित करें। पुनःप्रयास सीमा समाप्त होने के बाद जाँच कार्य को समीक्षा कतार में ले जाएँ, न कि हर मिनट बिना परिणाम के नए अनुरोध बनाएँ।
स्थिति अनुरोध का पुनरावृत्ति आमतौर पर सुरक्षित है, यदि विधि केवल डेटा पढ़ती है। निर्माण, रद्दीकरण, टॉप-अप, पुनःआरंभ और वापसी की विधियों को टाइमआउट के बाद यांत्रिक रूप से दोहराया नहीं जा सकता। इडेम्पोटेंट कुंजी या आपूर्तिकर्ता की स्पष्ट पुष्टि के बिना ऐसा पुनरावृत्ति ऑर्डर को दो बार बदल सकता है।
पुनःप्रयास सीमा की कमी यह है कि कुछ अपडेट मैन्युअल कार्य बन जाएँगे। अनंत पुनःप्रयास बदतर हैं: वे विफलता को छिपाते हैं, सीमाएँ खर्च करते हैं और लॉग विश्लेषण को जटिल बनाते हैं।
processing के बाद अंतिम स्थिति कैसे स्वीकार करें
देर से आए polling प्रतिक्रिया या पुराने वेबहुक के कारण completed से processing में उलटा संक्रमण न होने दें। प्रत्येक अपडेट पर आपूर्तिकर्ता से घटना का समय, संस्करण क्रमांक यदि उपलब्ध हो, और वर्तमान आंतरिक स्थिति की तुलना करें।
- new और pending processing, canceled या failed में जा सकते हैं।
- processing completed, partial, canceled या failed में जा सकता है।
- partial को स्वचालित रूप से completed न मानें।
- completed, canceled और failed आमतौर पर अंतिम माने जाते हैं और स्वचालित वापसी को रोकते हैं।
- अज्ञात स्थिति या अमान्य संक्रमण के लिए अलग जाँच आवश्यक है।
कठोर संक्रमण तालिका की भी कमी है: आपूर्तिकर्ता एक वैध नई स्थिति जोड़ सकता है। इसलिए मूल स्थिति सहेजें और उसे आंतरिक वर्गीकरण से न मिटाएँ।
partial और ऑर्डर शेष को कैसे संभालें
Partial का अर्थ है कि मूल वॉल्यूम का केवल एक भाग पुष्टि किया गया है। API प्रतिक्रिया में वास्तविक निष्पादित मात्रा, शेष, कारण और मुआवजे की जानकारी हो सकती है। इन मानों को अलग से संग्रहीत करें: ऑर्डर के मूल वॉल्यूम को निष्पादित मात्रा से न बदलें।
अंतिम प्रतिक्रिया का उदाहरण इस प्रकार हो सकता है:
{
"order_id": "
"status": "partial",
"completed_quantity": 700,
"remains": 300,
"refund": "मान_या_फ़ील्ड_की_अनुपस्थिति"
}
पहले निर्धारित करें कि API वास्तव में क्या पुष्टि करता है: वापसी पहले ही हो चुकी है, वापसी केवल नियोजित है, शेष रद्द किया गया है या सहायता से संपर्क आवश्यक है। यदि वापसी के बारे में फ़ील्ड नहीं है, तो शेष को स्वचालित रूप से मुआवजा प्राप्त न मानें।
अधूरे भाग को अलग निर्णय के बिना पुनःआरंभ न करें। आपूर्तिकर्ता अभी भी गणना पूरी कर रहा हो सकता है, प्लेटफ़ॉर्म आँकड़े देरी से अपडेट हो सकते हैं, और दोबारा अनुरोध डुप्लिकेट प्रचार बना सकता है। पुष्टि की प्रतीक्षा की कमी — शेष तुरंत बंद नहीं होगा, लेकिन अतिरिक्त ऑर्डर नहीं बनेगा।
वेबहुक नियंत्रण जाँच का स्थान नहीं लेते
वेबहुक अगले polling की प्रतीक्षा किए बिना घटना के तुरंत बाद ऑर्डर कार्ड अपडेट करने की अनुमति देता है। हैंडलर में बाहरी ID से ऑर्डर खोजें, हस्ताक्षर या गोपनीय जाँचें, घटना ID सहेजें और स्वीकार्यता की जाँच के बाद ही संक्रमण लागू करें।
वेबहुक की पुनः डिलीवरी सुरक्षित होनी चाहिए: एक ही घटना को नया परिवर्तन न मानें। घटनाएँ क्रम से बाहर भी आ सकती हैं, इसलिए देर से आए processing के आधार पर अंतिम ऑर्डर को वापस न ले जाएँ।
स्थिर वेबहुक के साथ भी नियंत्रण polling आवश्यक है। वेबहुक की कमी — अधिक जटिल सेटअप: सुलभ हैंडलर, नकली अनुरोधों से सुरक्षा, डीडुप्लिकेशन और घटना लॉग आवश्यक है।
processing और अटकाव के समय ग्राहक को क्या दिखाएँ
इंटरफ़ेस में पूरा तकनीकी JSON प्रदर्शित करने की आवश्यकता नहीं है। processing के लिए "ऑर्डर कार्य में है" स्थिति पर्याप्त है। यदि API ने विश्वसनीय प्रगति भेजी है, तो पुष्टि वॉल्यूम को मूल से अलग दिखाएँ और इसे अंतिम परिणाम के रूप में प्रस्तुत न करें।
जिस ऑर्डर ने आंतरिक नियंत्रण अवधि पार कर ली है, उसके लिए "निष्पादन की जाँच कर रहे हैं" जैसी स्पष्ट स्थिति का उपयोग करें। जब तक आपूर्तिकर्ता की प्रतिक्रिया से पुष्टि न हो, रद्दीकरण, वापसी या पूर्ण समापन की सूचना न दें।
सूचनाएँ ऑर्डर स्वीकार करने, अंतिम निष्पादन, partial, रद्दीकरण, त्रुटि और जाँच की आवश्यकता पर उपयोगी हैं। प्रत्येक polling के बाद संदेश शोर पैदा करते हैं और ग्राहक को अनुरोध की वास्तविक स्थिति समझने में मदद नहीं करते।
प्रसंस्करण लॉग में कौन-सी प्रविष्टियाँ आवश्यक हैं
प्रतिक्रिया इतिहास अटके हुए processing, खोए हुए वेबहुक, आंशिक निष्पादन पर विवाद और इंटरफ़ेस तथा API के बीच अंतर को सुलझाने में मदद करता है। प्रत्येक कॉल के लिए बाहरी ID, अपडेट स्रोत, अनुरोध और प्रतिक्रिया का समय, HTTP कोड, मूल स्थिति, सामान्यीकृत स्थिति, प्रगति, शेष और तकनीकी त्रुटि का पाठ सहेजें।
सामान्य लॉग में API कुंजी, टोकन, हस्ताक्षर और अन्य गोपनीय जानकारी न लिखें। कच्ची प्रतिक्रियाओं तक पहुँच सीमित करें: उनमें ऐसा डेटा हो सकता है जो सहायता इंटरफ़ेस में नहीं होना चाहिए।
लॉन्च से पहले बार-बार processing, प्रगति की अनुपस्थिति, टाइमआउट, 429, 5xx त्रुटि, गलत JSON, देर से वेबहुक, डुप्लिकेट वेबहुक, partial, canceled और अज्ञात स्थिति वाले परिदृश्यों की जाँच करें। परीक्षण मोड एकीकरण संरचना के लिए उपयोगी है, लेकिन इसकी कमी यह है कि यह वास्तविक कतारों और कार्यशील API की देरी को दोहरा नहीं सकता।
Last Articles
डिज़ाइन और कार्यक्षमता में क्या बदला हमने साइट को अपडेट किया है ताकि इसके साथ काम करना तेज़ और आसान हो। मुख्य बदलाव इंटरफ़ेस, व्यक्तिगत कैबिनेट और ऑर..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. हमारे सभी दर्शकों के लिए 15% छूट के लिए प्रोमो कोड "December2025" का उपयोग करें2. हमने 1 जनवरी तक अपने कॉन्फ़िगरेशन टूल और सबसे सस्ते दर्शक श्रेणी ..
चिकोटी सेवाएं हैं स्थिर रूप से काम करना, इसलिए हम दस्तों, पुनर्विक्रेताओं के साथ सहयोग करने के लिए तैयार हैं, सेवा मालिक, बॉट मालिक, और कई अन्य । ..
हम हमारी ट्विच व्यूअर सेवाओं को पूरी तरह से अपडेट कर दिया है, और वे अब हैं स्थिरतापूर्वक काम करना । हम केवल दर्शकों के लिए उच्च गुणवत्ता वाले आईप..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
साझेदारी सेवाओं और रेफरल कार्यक्रम की भारी लोकप्रियता के कारण, हमने एक सहयोग तालिका बनाई है। सार बहुत सरल है: अधिक लाइव दर्शक - हमारी ओर से अधिक विज्ञ..
स्ट्रीमर्स के लिए हमारी सेवाएं
Shopee
Bigo
कंटेंट क्रिएटर्स के लिए हमारी सेवाएं
