बैकएंड इंटरव्यू: किसी API को HTTP 202 Accepted कब लौटाना चाहिए?

प्रॉम्प्ट और पृष्ठभूमि (Setting)

आपके पास एक बड़े निर्यात (export) के लिए POST /exports का स्वामित्व है। अनुरोध इनपुट को मान्य करता है और कार्य शुरू करता है, लेकिन निर्यात में कई मिनट लग सकते हैं। साक्षात्कारकर्ता पूछता है कि क्या 200, 201, या 202 लौटाया जाना चाहिए, और क्लाइंट को अंतिम परिणाम कैसे पता चलता है।

मान लें कि सर्वर एक निर्यात रिकॉर्ड को स्थायी (persist) कर सकता है और कार्य को कतारबद्ध (enqueue) कर सकता है। क्लाइंट का टाइमआउट हो सकता है और वह अनुरोध दोहरा सकता है। उत्तर में केवल स्थिति कोड का नाम ही नहीं, बल्कि अनुबंध (contract) को भी परिभाषित करना चाहिए।

साक्षात्कारकर्ता क्या जांचता है

• क्या आप "संसाधन बनाया गया (resource created)" और "बाद के प्रसंस्करण के लिए अनुरोध स्वीकृत (request accepted for later processing)" के बीच अंतर करते हैं।
• क्या आप एक स्थायी स्थिति संसाधन (durable status resource), अंतिम अवस्थाओं (terminal states), और त्रुटि विवरणों को मॉडल करते हैं।
• क्या कोई पुनः प्रयास (retry) दो निर्यात बना सकता है या मूल प्रतिक्रिया को खो सकता है।
• क्या वितरित लेनदेन (distributed transaction) का दिखावा किए बिना कतार (queue) और डेटाबेस अपडेट विश्वसनीय हैं।

उत्तर देने से पहले स्पष्टीकरण संबंधी प्रश्न

1. क्या POST तुरंत एक स्थायी निर्यात संसाधन बनाता है? यदि हाँ, तो 201 Created उस संसाधन का वर्णन कर सकता है; यदि नहीं, तो 202 एक स्वीकृत कार्य की पुष्टि कर सकता है।
2. क्या उसी तार्किक अनुरोध का पुनः प्रयास किया जा सकता है? यदि हाँ, तो इसके लिए एक idempotency key या कॉलर द्वारा प्रदान की गई operation ID की आवश्यकता होगी।
3. क्या क्लाइंट को पोलिंग (polling), वेबहुक (webhooks), या दोनों की आवश्यकता है? यह स्थिति प्रतिनिधित्व (status representation) और अधिसूचना अनुबंध (notification contract) को बदल देता है।
4. निर्यात की गई फ़ाइलों के लिए प्रतिधारण (retention) और प्राधिकरण (authorization) नियम क्या हैं? किसी कार्य का पूर्ण होना उसके परिणाम को प्रत्येक कॉलर के लिए उजागर करने की अनुमति नहीं है।

30-सेकंड का उत्तर ढांचा

"मैं 202 Accepted केवल तभी लौटाता हूँ जब प्रसंस्करण स्थगित (deferred) हो और अंतिम परिणाम तैयार न हो। मैं पहले एक स्थायी कार्य रिकॉर्ड (durable job record) बनाता हूँ, फिर उसका स्थिति URI और एक ऑपरेशन पहचानकर्ता लौटाता हूँ। क्लाइंट बैकऑफ़ के साथ उस URI को पोल करता है या एक प्रमाणित कॉलबैक प्राप्त करता है। एक idempotency key पुनः प्रयासों को उसी कार्य और प्रतिक्रिया पर मैप करती है। कार्य स्पष्ट अवस्थाओं जैसे queued, running, succeeded, और failed से होकर गुजरता है; वर्कर और आउटबॉक्स पुनः प्रयास करने योग्य (retryable) हैं, और स्थिति एंडपॉइंट सत्य का स्रोत (source of truth) बना रहता है।"

चरण-दर-चरण गहन विश्लेषण (Deep dive)

1. संसाधन जीवनचक्र से स्थिति (status) चुनें

200 OK का अर्थ है कि अनुरोध एक प्रतिनिधित्व (representation) के साथ पूरा हो गया। 201 Created का अर्थ है कि एक संसाधन बनाया गया था और उसे पहचानने योग्य होना चाहिए। 202 Accepted का अर्थ है कि अनुरोध स्वीकार कर लिया गया था, जबकि प्रसंस्करण शुरू या समाप्त नहीं भी हो सकता है; यह अंतिम सफलता का वादा नहीं करता है।

यदि निर्यात रिकॉर्ड समकालिक रूप से (synchronously) बनाया गया है और वह संसाधन है जिसे कॉलर प्रबंधित करेगा, तो मैं उस संसाधन के साथ 201 लौटा सकता हूँ। यदि API केवल कार्य को स्वीकार करता है और परिणाम लंबित है, तो 202 के साथ एक मॉनिटर URI अधिक स्पष्ट है। यह चुनाव अवलोकनीय जीवनचक्र का अनुसरण करता है, न कि इस तथ्य का कि संयोग से एक कतार (queue) मौजूद है।

2. प्रतिक्रिया को कार्रवाई योग्य (actionable) बनाएं

एक ऑपरेशन ID, एक स्थिति URL, और state, टाइमस्टैम्प्स, और एक सुरक्षित पुनः प्रयास संकेत (retry hint) के साथ एक प्रतिनिधित्व लौटाएं। एक न्यूनतम प्रतिक्रिया इस तरह दिख सकती है:

HTTP/1.1 202 Accepted
Location: /exports/exp_123
Retry-After: 5
Content-Type: application/json

{"id":"exp_123","state":"queued","status_url":"/exports/exp_123"}

स्थिति संसाधन को प्रत्येक पठन (read) पर प्राधिकरण (authorization) का उपयोग करना चाहिए। queued और running गैर-अंतिम (non-terminal) हैं। succeeded में एक अल्पकालिक डाउनलोड संदर्भ शामिल है; failed में स्टैक ट्रेस लीक किए बिना एक स्थिर त्रुटि कोड और एक निवारण संकेत (remediation hint) शामिल है। क्लाइंट को संसाधन के उसकी प्रतिधारण विंडो (retention window) के बाद गायब होने को सहन करना चाहिए।

3. पुनः प्रयासों को अभिसरित (converge) बनाएं

कार्य बनाने वाले ऑपरेशनों के लिए Idempotency-Key की आवश्यकता होती है। प्रासंगिक अनुरोध का एक हैश, परिणामी जॉब ID, और प्रतिक्रिया स्थिति को स्थायी (persist) करें। उसी अनुरोध के साथ एक दोहराई गई कुंजी मूल परिणाम लौटाती है; एक अलग अनुरोध के साथ वही कुंजी एक क्लाइंट त्रुटि है। पहचान नियम के रूप में केवल एक समय विंडो का उपयोग न करें, क्योंकि देर से किया गया पुनः प्रयास विंडो के बाद आ सकता है।

API अभी भी दो निर्यातों के लिए दो अलग-अलग कुंजियों को स्वीकार कर सकता है। Idempotency एक तार्किक ऑपरेशन के लिए डुप्लिकेट कार्य को रोकता है; यह वर्करों को ठीक-ठीक एक बार (exactly once) निष्पादित होने वाला नहीं बनाता है।

4. डेटाबेस-टू-क्यू अंतर को पाटें (Close the database-to-queue gap)

एक डेटाबेस लेनदेन में निर्यात पंक्ति और एक आउटबॉक्स इवेंट लिखें। एक रिले लंबित आउटबॉक्स पंक्तियों को प्रकाशित करता है और ब्रोकर द्वारा उन्हें स्वीकार करने के बाद उन्हें डिलीवर चिह्नित करता है। एक क्रैश उसी इवेंट को फिर से प्रकाशित कर सकता है, इसलिए उपभोक्ता निर्यात ID को idempotency key के रूप में उपयोग करता है। यह इस अपरिवर्तनीय (invariant) को संरक्षित करता है कि एक कमिट किया गया कार्य अंततः खोजने योग्य है, बिना यह दावा किए कि डेटाबेस और ब्रोकर परमाणु रूप से (atomically) कमिट होते हैं।

वर्कर सशर्त संक्रमणों (conditional transitions) के साथ स्थिति को अपडेट करता है, उदाहरण के लिए queued -> running -> succeeded|failed। एक पुराना पुनः प्रयास succeeded को वापस running पर नहीं ले जा सकता है। मेट्रिक्स को कतार की आयु (queue age), चलने की आयु (running age), अंतिम विफलता दर (terminal failure rate), और आउटबॉक्स अंतराल (outbox lag) को उजागर करना चाहिए।

5. पोलिंग, कॉलबैक और रद्दीकरण (cancellation) को परिभाषित करें

स्थिति एंडपॉइंट ETag या एक संस्करण का समर्थन करता है ताकि पोलिंग सशर्त अनुरोधों (conditional requests) का उपयोग कर सके। क्लाइंट सर्वर संकेत के साथ घातीय बैकऑफ़ (exponential backoff) लागू करते हैं और अंतिम अवस्था के बाद पोलिंग बंद कर देते हैं। वेबहुक एक अनुकूलन (optimization) हैं, परिणाम जानने का एकमात्र तरीका नहीं: डिलीवरी विफल हो सकती है, इसलिए क्लाइंट को स्थिति संसाधन को पढ़कर सामंजस्य (reconcile) स्थापित करना चाहिए।

रद्दीकरण एक अलग कमांड है, जैसे POST /exports/exp_123/cancel। यह केवल रद्द करने योग्य अवस्थाओं के लिए स्वीकार किया जाता है और स्वयं idempotent होता है। एक कार्य जो पहले ही succeeded तक पहुँच चुका है, उसे देर से किए गए रद्दीकरण द्वारा वापस नहीं लाया (rolled back) जा सकता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं सबसे पहले यह पूछूंगा कि क्या निर्यात रिकॉर्ड इस कॉल द्वारा बनाया गया संसाधन है। यदि यह है, तो मैं 201 और रिकॉर्ड लौटा सकता हूँ। एक स्थगित ऑपरेशन के लिए जिसका परिणाम तैयार नहीं है, मैं एक ऑपरेशन ID और एक प्रमाणित स्थिति URL के साथ 202 लौटाता हूँ। मुझे एक idempotency key की आवश्यकता होती है, मैं अनुरोध फ़िंगरप्रिंट और जॉब ID संग्रहीत करता हूँ, और पुनः प्रयास के लिए वही प्रतिनिधित्व लौटाता हूँ।

लेनदेन निर्यात पंक्ति और आउटबॉक्स इवेंट को एक साथ लिखता है। एक रिले और एक idempotent उपभोक्ता कम से कम एक बार (at least once) डिलीवरी को संभालते हैं। स्थिति स्टेट मशीन एकदिशीय (monotonic) है: queued, running, फिर succeeded या failed। क्लाइंट सशर्त अनुरोधों और बैकऑफ़ के साथ पोल करता है; एक वेबहुक केवल एक गतिवर्धक (accelerator) है। मैं कतार की आयु, आउटबॉक्स अंतराल, और अंतिम त्रुटियों को प्रकाशित करता हूँ, और मैं प्रतिधारण, प्राधिकरण, डाउनलोड समाप्ति और रद्दीकरण को अलग से परिभाषित करता हूँ। 202 स्वीकृति की पुष्टि करता है, सफलता की नहीं।

सामान्य गलतियाँ

• त्रुटि: 202 को इस प्रमाण के रूप में मानना ​​कि कार्य सफल होगा → यह क्यों विफल होता है: RFC शब्दार्थ प्रसंस्करण को विफल होने या कभी शुरू न होने की अनुमति देता है → सुधार: अंतिम विफलता और प्रतिधारण व्यवहार को उजागर करें।
• त्रुटि: बिना किसी मॉनिटर URL के केवल 202 लौटाना → यह क्यों विफल होता है: क्लाइंट बिना अनुमान लगाए स्थिति का पता नहीं लगा सकते → सुधार: एक प्रमाणित स्थिति संसाधन और ऑपरेशन ID लौटाएं।
• त्रुटि: डेटाबेस कमिट के बाद कतार प्रकाशन (queue publish) पर भरोसा करना → यह क्यों विफल होता है: एक क्रैश ऐसा कार्य बना देता है जिसे कोई वर्कर नहीं देख सकता → सुधार: transactional outbox और पुनः चलाने योग्य रिले का उपयोग करें।
• त्रुटि: यह मान लेना कि कतार ठीक-ठीक एक बार (exactly-once) निष्पादन देती है → यह क्यों विफल होता है: पुनः प्रयास और क्रैश डिलीवरी को डुप्लिकेट कर सकते हैं → सुधार: उपभोक्ताओं को idempotent और संक्रमणों को सशर्त बनाएं।
• त्रुटि: प्रत्येक idempotency-key के पुन: उपयोग पर सफलता लौटाना → यह क्यों विफल होता है: एक कुंजी बदले हुए अनुरोध को छिपा सकती है → सुधार: अनुरोध फ़िंगरप्रिंट की तुलना करें और बेमेल होने पर अस्वीकार करें।

अनुवर्ती प्रश्न और प्रतिक्रियाएँ

क्या इस एंडपॉइंट को इसके बजाय 201 लौटाना चाहिए?

जब सिंक्रोनस कॉल एक स्थायी निर्यात संसाधन बनाता है और इसे Location के साथ पहचान सकता है, तो 201 लौटाएं। जब सार्थक परिणाम स्थगित हो और प्रतिक्रिया केवल स्वीकृति की पुष्टि करती हो, तो 202 लौटाएं। कुछ API जॉब संसाधन के लिए 201 का उपयोग कर सकते हैं, जबकि अभी भी एक लंबित स्थिति को उजागर कर रहे हैं; दस्तावेज़ में बताएं कि स्थिति किस संसाधन का वर्णन करती है।

क्या होगा यदि क्लाइंट कभी पोल नहीं करता है?

दस्तावेजीकृत प्रतिधारण अवधि के लिए कार्य स्थिति को स्थायी रखें, एक वैकल्पिक प्रमाणित वेबहुक भेजें, और ऑपरेशन ID द्वारा बाद में GET की अनुमति दें। कॉलबैक विफलता को एकमात्र स्थिति पथ को हटाना नहीं चाहिए। समाप्त हो चुके डाउनलोड URL और प्राधिकरण जांच तब भी लागू होती हैं जब क्लाइंट दिनों बाद लौटता है।

क्या वर्कर कार्य को दो बार अपडेट कर सकता है?

हाँ, डिलीवरी आमतौर पर कम से कम एक बार (at least once) होती है। एक अद्वितीय निर्यात ID, सशर्त स्थिति संक्रमण, और idempotent आउटपुट राइट्स का उपयोग करें। एक डुप्लिकेट succeeded इवेंट हानिरहित होना चाहिए; अंतिम अवस्था से वापस running में संक्रमण को अस्वीकार और लॉग किया जाना चाहिए।