बैकएंड इंटरव्यू: आप HTTP 415 Unsupported Media Type अनुबंध (contract) को कैसे डिज़ाइन करेंगे?

संकेत और दायरा (Prompt and scope)

एक API POST के लिए JSON और CBOR तथा PATCH के लिए JSON Patch स्वीकार करता है। गलत Content-Type, सामग्री एन्कोडिंग, या पैच-दस्तावेज़ प्रारूप भेजने के बाद क्लाइंट्स को 415 प्राप्त होता है। सर्वर वर्गीकरण, प्रतिक्रिया हेडर, त्रुटि बॉडी, क्लाइंट रिकवरी, और संस्करण विकास को डिज़ाइन करें।

यह एक बैकएंड API अनुबंध से संबंधित प्रश्न है। मीडिया प्रकार और प्रारूप धारणाएँ हैं, आवृत्ति के दावे नहीं।

साक्षात्कारकर्ता क्या परख रहा है

• क्या आप अनुरोध Content-Type और Content-Encoding को प्रतिक्रिया Accept से अलग करते हैं।
• क्या आप प्रत्येक पार्स त्रुटि को इस तरह लेबल करने के बजाय 415 का सीमित और सटीक उपयोग करते हैं।
• क्या आप अनुकूलता बनाए रखते हुए Accept-Patch के साथ PATCH क्षमता को उजागर करते हैं।
• क्या त्रुटि असुरक्षित स्वचालित रीप्ले के बिना कार्रवाई योग्य है।

पूछने के लिए स्पष्टीकरण संबंधी प्रश्न

1. क्या 415 मीडिया प्रकार, सामग्री एन्कोडिंग, या विधि क्षमता (method capability) के कारण हुआ है?
2. क्या क्लाइंट बॉडी को फिर से एन्कोड कर सकता है, और क्या कोई स्थिर अनुरोध आईडी (request ID) है?
3. कौन से पैच प्रारूप और संसाधन-संस्करण स्थितियाँ समर्थित हैं?
4. क्या कोई गेटवे Content-Type, एन्कोडिंग, या त्रुटि बॉडी को फिर से लिख (rewrite) सकता है?
5. पुराने क्लाइंट्स को बाधित किए बिना एक नया मीडिया प्रकार कैसे रोल आउट होगा?

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

“415 का अर्थ है कि लक्षित विधि अनुरोध प्रतिनिधित्व के प्रारूप को अस्वीकार करती है। सर्वर Content-Type, पैरामीटर, और Content-Encoding को पार्स करता है, फिर विधि और संसाधन क्षमता के आधार पर एक पार्सर चुनता है। Accept उन प्रतिक्रिया प्रारूपों का वर्णन करता है जो क्लाइंट चाहता है; यह उसके द्वारा भेजे गए पैच दस्तावेज़ का वर्णन नहीं करता है। एक PATCH संसाधन Accept-Patch के साथ समर्थित दस्तावेज़ प्रकारों का विज्ञापन कर सकता है। त्रुटि एक स्थिर कोड, प्राप्त और अनुमत मान, और एक अनुरोध आईडी लौटाती है। सुरक्षित पुन: एन्कोडिंग और रीप्ले विश्लेषण के बाद ही पुनः प्रयास करें।”

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

1. तीन हेडर सिमेंटिक्स को अलग करें

Content-Type अनुरोध बॉडी के मीडिया प्रकार का वर्णन करता है, Content-Encoding ट्रांसफर कोडिंग का वर्णन करता है, और Accept उन प्रतिक्रिया अभ्यावेदन (response representations) का वर्णन करता है जिन्हें क्लाइंट प्राप्त कर सकता है। सर्वर को PATCH दस्तावेज़ को वर्गीकृत करने के लिए Accept का उपयोग नहीं करना चाहिए या डीकंप्रेशन, करप्शन, और असमर्थित मीडिया को एक ही कारण में नहीं मिलाना चाहिए।

2. विधि और संसाधन क्षमता को मैप करें

प्रत्येक विधि और संसाधन समर्थित मीडिया प्रकारों और मापदंडों की घोषणा करते हैं। उदाहरण के लिए, POST application/json और application/cbor स्वीकार करता है, जबकि PATCH एक पंजीकृत JSON Patch दस्तावेज़ प्रकार स्वीकार करता है। पार्स करने से पहले प्रकार और एन्कोडिंग की जाँच करें; पार्स करने के बाद भी स्कीमा, प्राधिकरण, और व्यावसायिक सत्यापन चलाएँ।

PATCH /documents/42 HTTP/1.1
Content-Type: application/json-patch+json
Accept: application/json
Content-Length: 128

3. एक सटीक 415 लौटाएँ

मीडिया प्रकार या सामग्री एन्कोडिंग असमर्थित होने पर एक स्थिर त्रुटि कोड के साथ 415 लौटाएँ। अमान्य फ़ील्ड वाले मान्य सिंटैक्स के लिए डोमेन सत्यापन त्रुटि का उपयोग करें, और विकृत सामग्री के लिए एक स्पष्ट पार्स त्रुटि का उपयोग करें। एक Accept प्रतिक्रिया हेडर उन अभ्यावेदनों का वर्णन कर सकता है जिन्हें सर्वर लौटा सकता है; यह अनुरोध मीडिया प्रकारों की सूची नहीं है।

4. PATCH क्षमता का विज्ञापन करें

RFC 5789 Accept-Patch को परिभाषित करता है; एक संसाधन OPTIONS या एक सफल प्रतिक्रिया में समर्थित पैच-दस्तावेज़ मीडिया प्रकारों की घोषणा कर सकता है। क्लाइंट तब JSON Patch या कोई अन्य प्रारूप चुन सकता है, जबकि सर्वर अभी भी संसाधन संस्करण, पथ, और प्राधिकरण की जाँच करता है। विज्ञापन वास्तविक पार्सर सेट से मेल खाना चाहिए।

5. क्लाइंट रिकवरी को सुरक्षित बनाएं

415 के बाद, क्लाइंट स्थिर कोड और अनुमत प्रकार को पढ़ता है, बॉडी को फिर से एन्कोड करता है, या एक संगत एंडपॉइंट चुनता है। स्वचालित पुनः प्रयास के लिए एक पुनर्निर्माण योग्य बॉडी, कोई अपरिवर्तनीय दुष्प्रभाव नहीं, और उसी आइडेम्पोटेंसी कुंजी की आवश्यकता होती है। ऐसे PATCH को फिर से सबमिट न करें जो शायद सफल हो चुका हो, और 415 को अस्थायी अनुपलब्धता के रूप में न लें।

6. परिवर्तनों को रोल आउट और मॉनिटर करें

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

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

“मैं अनुरोध और प्रतिक्रिया प्रारूपों को अलग करता हूँ। सर्वर विधि और संसाधन द्वारा Content-Type और Content-Encoding की जाँच करता है, केवल समर्थित अभ्यावेदनों को पार्स करता है, फिर स्कीमा और व्यावसायिक सत्यापन चलाता है; Accept प्रतिक्रिया वार्ता के लिए है। PATCH संसाधन Accept-Patch के साथ दस्तावेज़ प्रकारों का विज्ञापन करते हैं, लेकिन प्रत्येक अनुरोध अभी भी संस्करण और प्राधिकरण की जाँच करता है। 415 बॉडी एक स्थिर कोड, प्राप्त और अनुमत मान, और अनुरोध आईडी प्रदान करती है। क्लाइंट केवल सुरक्षित पुन: एन्कोडिंग के बाद ही पुनः प्रयास करते हैं। नए प्रकार एक अनुकूलता मैट्रिक्स और मेट्रिक्स के माध्यम से रोल आउट होते हैं ताकि गेटवे या पुराने SDK चुपचाप सिमेंटिक्स को न बदलें।”

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

• अनुरोध बॉडी को वर्गीकृत करने के लिए Accept का उपयोग करना → अनुरोध और प्रतिक्रिया वार्ता आपस में मिल जाती है → Content-Type और Content-Encoding का निरीक्षण करें।
• प्रत्येक पार्स विफलता के लिए 415 लौटाना → क्लाइंट सुधार का विकल्प नहीं चुन सकते → मीडिया, सिंटैक्स, और डोमेन त्रुटियों को अलग करें।
• पार्सर के बिना Accept-Patch का विज्ञापन करना → क्षमता अनुबंध झूठा हो जाता है → कार्यान्वयन के विरुद्ध घोषणा को मान्य करें।
• 415 के बाद उसी बॉडी के साथ पुनः प्रयास करना → यह विफल हो जाएगा या इसके दुष्प्रभाव दोहराए जाएंगे → एन्कोडिंग बदलें और रीप्ले सुरक्षा की पुष्टि करें।
• प्रकार को केवल एप्लिकेशन में लॉग करना → गेटवे पुनर्लेखन अदृश्य हो जाते हैं → प्रति हॉप हेडर और अनुरोध आईडी की तुलना करें।

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

यदि Content-Type मान्य है लेकिन Content-Encoding असमर्थित है, तो क्या 415 अभी भी सही है?

RFC 9110 एक अस्वीकार्य अनुरोध सामग्री कोडिंग को 415 के दायरे में शामिल करता है। त्रुटि में एन्कोडिंग की व्याख्या करें, फिर यह तय करने से पहले कि क्या बॉडी और ऑपरेशन को सुरक्षित रूप से पुनः प्रयास किया जा सकता है, डीकंप्रेस करें या समर्थित एन्कोडिंग का चयन करें।

केवल अनुमत प्रकारों की सूची ही क्यों न लौटाई जाए?

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

आप CBOR को सुरक्षित रूप से कैसे जोड़ते हैं?

इसे पहले गैर-महत्वपूर्ण संसाधनों पर सक्षम करें, गेटवे पास-थ्रू, पार्सर संसाधन सीमाओं, स्कीमा समतुल्यता, और लॉग रिडक्शन को सत्यापित करें। JSON फ़ॉलबैक बनाए रखें और क्लाइंट संस्करण द्वारा 415, पार्स विफलताओं, और व्यावसायिक परिणामों की तुलना करें।