बैकएंड इंटरव्यू: HTTP Prefer को idempotency और कैशिंग को प्रभावित किए बिना प्रतिक्रियाओं पर बातचीत (negotiate) कैसे करनी चाहिए?

प्रॉम्प्ट और दायरा

एक बैच राइट API अलग-अलग बैंडविड्थ और लेटेंसी लक्ष्यों वाले क्लाइंट्स को सेवा प्रदान करता है: कुछ को केवल स्थिति (status) की आवश्यकता होती है, कुछ को संपूर्ण संसाधन प्रतिनिधित्व (resource representation) की आवश्यकता होती है, और कुछ पोलिंग से बचने के लिए कुछ सेकंड प्रतीक्षा करेंगे। RFC 7240 का उपयोग करते हुए, Prefer अनुरोध हेडर, Preference-Applied प्रतिक्रिया हेडर, त्रुटि प्रबंधन (error handling), कैशिंग और फ़ॉलबैक व्यवहार को डिज़ाइन करें।

Prefer एक अनुरोध प्राथमिकता (request preference) है, सर्वर के लिए कोई अनिवार्यता (server mandate) नहीं है। यह प्रश्न प्रोटोकॉल सिमेंटिक्स और API अनुबंधों (contracts) का परीक्षण करता है; यह यह मानकर नहीं चलता कि प्रत्येक प्रॉक्सी प्राथमिकता हेडर को सुरक्षित रखता है।

इंटरव्यूअर क्या जांच रहा है

• क्या आप क्लाइंट प्राथमिकता और सर्वर प्रॉमिस के बीच अंतर करते हैं और यह रिपोर्ट करते हैं कि वास्तव में क्या लागू किया गया था।
• क्या आप return=minimal, return=representation, respond-async, और wait का सही उपयोग करते हैं।
• क्या आप प्रतिक्रिया वेरिएंट्स, Vary, कैश कुंजियों (cache keys), और प्रॉक्सी संगतता को ध्यान में रखते हैं।
• क्या प्राथमिकता का सम्मान न होने पर भी पुनः प्रयास (retries), idempotency keys और एसिंक्रोनस जॉब स्थिति सुरक्षित रहती हैं।

स्पष्टीकरण वाले प्रश्न

1. क्या API एक सुरक्षित रीड (safe read) है या साइड-इफेक्टिंग राइट (side-effecting write), और क्या इसके पास पहले से ही एक idempotency key है?
2. पूर्ण प्रतिनिधित्व का आकार, जनरेशन लागत और अधिकतम प्रतीक्षा समय क्या है?
3. क्या क्लाइंट्स 202 और एक स्थिति संसाधन (status resource), पोलिंग, या कॉलबैक स्वीकार कर सकते हैं?
4. क्या मिडलवेयर/मिडिलबॉक्स Prefer को अग्रेषित (forward) करेंगे, और क्या कैश साझा (shared) किए जा सकते हैं?
5. प्राथमिकता का सम्मान न होने पर क्लाइंट्स को कौन से स्थिर फ़ील्ड (stable fields) देखने चाहिए?

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

“Prefer एक क्लाइंट प्राथमिकता व्यक्त करता है जिसे सर्वर अनदेखा कर सकता है या आंशिक रूप से लागू कर सकता है; Preference-Applied रिपोर्ट करता है कि क्या लागू किया गया था। एक राइट प्रतिक्रिया को कम करने के लिए return=minimal का उपयोग कर सकता है, एक सिंक्रोनस कॉलर return=representation का अनुरोध कर सकता है, और एक लंबा ऑपरेशन सीमित wait के साथ respond-async का उपयोग कर सकता है। मैं idempotency keys, एक 202 स्थिति संसाधन, कैश Vary, और क्लाइंट फ़ॉलबैक को एक साथ डिज़ाइन करूँगा: Preference-Applied के बिना, डिफ़ॉल्ट प्रतिक्रिया को पार्स करें और कभी यह न मानें कि प्राथमिकता सफल हो गई।”

चरण-दर-चरण डिज़ाइन

1. प्राथमिकता को अनदेखा करने योग्य बातचीत (ignorable negotiation) के रूप में मानें

RFC 7240 Prefer अनुरोध हेडर और Preference-Applied प्रतिक्रिया हेडर को परिभाषित करता है। एक सर्वर किसी प्राथमिकता को अस्वीकार कर सकता है, इसलिए बॉडी और स्टेटस कोड को एक स्थिर डिफ़ॉल्ट अनुबंध की आवश्यकता होती है। किसी क्लाइंट को केवल इसलिए पार्सिंग नहीं छोड़नी चाहिए क्योंकि उसने Prefer भेजा था।

2. सही प्राथमिकता टोकन चुनें

return=minimal ऐसे राइट के लिए उपयुक्त है जिसे केवल पुष्टि की आवश्यकता होती है; return=representation ऐसे सिंक्रोनस कॉलर के लिए उपयुक्त है जिसे अपडेट किए गए संसाधन की आवश्यकता होती है। respond-async बताता है कि क्लाइंट एसिंक्रोनस प्रोसेसिंग स्वीकार करता है, जबकि wait=n एक प्रतीक्षा बजट देता है। ये संकेत हैं, SLA गारंटी नहीं।

3. प्रतिक्रिया में परिणाम की पुष्टि करें

प्राथमिकता का उपयोग होने पर Preference-Applied भेजें। जब इसका उपयोग नहीं किया जाता है, तो हेडर अनुपस्थित हो सकता है और डिफ़ॉल्ट अनुबंध लागू होता है। एक एसिंक्रोनस पथ 202, एक स्थिति URI और एक ट्रेस करने योग्य ID लौटाता है; सिंक्रोनस प्रतीक्षा बजट समाप्त होने के बाद, ऑपरेशन क्लाइंट द्वारा साइड इफ़ेक्ट को फिर से सबमिट करने के बजाय क्वेरिएबल (queryable) बना रहता है।

POST /v1/imports HTTP/1.1
Prefer: return=minimal, respond-async, wait=3
Idempotency-Key: imp-8f2

HTTP/1.1 202 Accepted
Preference-Applied: respond-async
Location: https://api.example/imports/jobs/42
Cache-Control: no-store

4. कैश वेरिएंट्स को संभालें

यदि एक सुरक्षित GET प्रतिनिधित्व Prefer के साथ बदलता है, तो Vary को सही ढंग से घोषित करें या प्राथमिकता-निर्भर प्रतिक्रियाओं को साझा कैश से बाहर रखें। राइट्स सामान्यतः no-store का उपयोग करते हैं। एक एसिंक्रोनस स्थिति संसाधन को शॉर्ट कैशिंग, ETags, या स्पष्ट पोलिंग शर्तों को परिभाषित करना चाहिए ताकि कोई मिडिलबॉक्स पुराना प्रोग्रेस डेटा न लौटाए।

5. Idempotency और फ़ॉलबैक को बनाए रखें

Prefer ऑपरेशन सिमेंटिक्स को नहीं बदलता है, इसलिए पुनः प्रयासों को अभी भी idempotency की आवश्यकता होती है। राइट्स के लिए एक idempotency या व्यावसायिक डिडुप्लीकेशन कुंजी (business deduplication key) का उपयोग करें। यदि कोई क्लाइंट 202, टाइमआउट, या कोई Preference-Applied नहीं देखता है, तो उसे संसाधन को फिर से बनाने के बजाय जॉब से क्वेरी करनी चाहिए या डिफ़ॉल्ट प्रतिक्रिया अनुबंध का पालन करना चाहिए।

6. ऑब्जर्वेबिलिटी और सीमाएं निर्धारित करें

प्राथमिकता टोकन रिकॉर्ड करें, क्या वे लागू किए गए थे, प्रतीक्षा अवधि, प्रतिक्रिया का आकार, 202 दर और प्रॉक्सी पथ। wait को सीमित करें, अत्यधिक मानों को अस्वीकार या छोटा (truncate) करें। मनमाने क्लाइंट स्ट्रिंग्स को महंगी निष्पादन प्रक्रियाओं में बदलने के बजाय अज्ञात प्राथमिकताओं को अनदेखा और रिकॉर्ड करें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

“मैं Prefer को एक अनदेखा करने योग्य क्लाइंट प्राथमिकता के रूप में मानूंगा, कोई वादा नहीं। एक राइट डिफ़ॉल्ट रूप से एक स्थिर स्थिति पर होता है; एक छोटा रिस्पॉन्स चाहने वाला क्लाइंट return=minimal भेजता है, संसाधन की आवश्यकता वाला क्लाइंट return=representation भेजता है, और एक लंबा जॉब सीमित wait के साथ respond-async का उपयोग करता है। सर्वर केवल तभी Preference-Applied भेजता है जब वह प्राथमिकता लागू करता है; एक एसिंक्रोनस परिणाम Location और जॉब ID के साथ 202 होता है। राइट्स idempotency keys का उपयोग करते हैं, रिस्पॉन्स जहां उपयुक्त हो no-store का उपयोग करते हैं, और प्रतिनिधित्व के अंतरों को Vary या कैश नीति के साथ अलग किया जाता है। Preference-Applied के बिना, क्लाइंट डिफ़ॉल्ट पार्सर का पालन करता है और जॉब से क्वेरी करता है, कभी भी साइड इफ़ेक्ट को डुप्लिकेट नहीं करता है।”

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

• Prefer को अनिवार्य मानना → सर्वर और प्रॉक्सी इसे अनदेखा कर सकते हैं → एक डिफ़ॉल्ट अनुबंध और Preference-Applied का उपयोग करें।
• प्रतीक्षा को पूरा होने की गारंटी मानना → लंबे जॉब्स अभी भी इससे अधिक समय ले सकते हैं → बजट को सीमित करें और 202 स्थिति संसाधन प्रदर्शित करें।
• एसिंक्रोनस टाइमआउट के बाद पुनः सबमिट करना → डुप्लिकेट साइड इफ़ेक्ट होते हैं → एक idempotency key का उपयोग करें और पहले क्वेरी करें।
• कैश वेरिएंट्स को अनदेखा करना → क्लाइंट्स को बेमेल प्रतिनिधित्व प्राप्त होता है → Vary सेट करें या कैश को अलग करें।
• मनमानी अज्ञात प्राथमिकताओं को निष्पादित करना → हमलावर संसाधन लागत को बढ़ा सकते हैं → टोकन को अनदेखा करें, रिकॉर्ड करें और सीमित करें।

अनुवर्ती प्रश्न और उत्तर

क्या अनुपस्थित Preference-Applied का मतलब है कि अनुरोध विफल हो गया?

नहीं। सर्वर अपना डिफ़ॉल्ट व्यवहार चुन सकता है या प्राथमिकता को अनदेखा कर सकता है। क्लाइंट को स्थिर डिफ़ॉल्ट अनुबंध को पार्स करना चाहिए और इसे केवल तभी विफलता कहना चाहिए जब प्रोटोकॉल या व्यावसायिक स्थिति कहे कि यह विफल रहा।

क्या प्रत्येक राइट return=minimal का उपयोग कर सकता है?

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

क्या wait=5 सर्वर को पांच सेकंड के लिए ब्लॉक करता है?

कोई पक्की गारंटी नहीं होती है। यह क्लाइंट की अधिकतम प्रतीक्षा प्राथमिकता है; सर्वर पहले समाप्त हो सकता है, इसे अनदेखा कर सकता है, या एसिंक्रोनस पर स्विच कर सकता है। सर्वर टाइमआउट, समवर्ती सीमाएं (concurrency limits) और संसाधन बजट अभी भी लागू होते हैं।