बैकएंड इंटरव्यू: किसी API को 204 No Content कब वापस करना चाहिए?

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

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

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

स्टेटस कोड को रिसोर्स सेमांटिक्स के रूप में समझें, न कि "कोई डेटा नहीं है" के शॉर्टकट के रूप में। 204 का अर्थ है बिना मैसेज कंटेंट के सफलता और इसमें कोई मैसेज बॉडी नहीं होनी चाहिए; 200 एक स्थिर रिप्रेजेंटेशन जैसे [] लौटा सकता है; 404 का अर्थ है कि लक्षित रिसोर्स अनुपस्थित है या उसका कोई वर्तमान रिप्रेजेंटेशन नहीं है। DELETE idempotency, कैश, SDK डिकोडिंग और OpenAPI दस्तावेज़ीकरण पर चर्चा करें।

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

1. टारगेट क्या है? एक रिसोर्स को डिलीट करना, एक रिसोर्स को अपडेट करना और एक कलेक्शन को क्वेरी करना अलग-अलग सेमांटिक्स रखते हैं।
2. क्या एक रिक्त कलेक्शन सामान्य परिणाम है? यदि हाँ, तो [] के साथ 200 आमतौर पर 204 की तुलना में एक स्थिर रिस्पॉन्स टाइप को बेहतर ढंग से बनाए रखता है।
3. क्या क्लाइंट्स को एक JSON आकार डिकोड करना चाहिए? एक जेनरेटेड क्लाइंट जो हमेशा बॉडी पढ़ता है, वह 204 को अप्रत्याशित EOF में बदल सकता है जब तक कि उसमें कोई स्पष्ट ब्रांच न हो।
4. क्या सफलता के लिए नए रिप्रेजेंटेशन, ETag या एसिंक्रोनस जॉब ID की आवश्यकता है? यदि ऐसा है, तो रिस्पॉन्स बॉडी बनाए रखें और 200, 201 या 202 चुनें।

अनुशंसित निर्णय और निष्कर्ष

ऑपरेशन और रिप्रेजेंटेशन की आवश्यकता के आधार पर कॉन्ट्रैक्ट को परिभाषित करें:

• बिना किसी रिप्रेजेंटेशन के सफल DELETE /users/42 204 का उपयोग कर सकता है। यदि बार-बार डिलीट करने को idempotent सफलता के रूप में परिभाषित किया गया है, तो यह 204 भी रह सकता है, लेकिन इसे दस्तावेज़ित करें।
• यदि GET /users?team=none बिना किसी सदस्य के मौजूदा कलेक्शन पाता है, तो लिस्ट टाइप को बनाए रखने के लिए 200 और [] वापस करें; शून्य पंक्तियाँ कोई अनुपलब्ध रिसोर्स नहीं हैं।
• यदि GET /users/42 टारगेट नहीं ढूंढ पाता है, तो 404 वापस करें। यह टारगेट-रिसोर्स सेमांटिक्स है, न कि रिक्त-सूची सेमांटिक्स।
• यदि PUT /users/42 सफल होता है और क्लाइंट को नए रिप्रेजेंटेशन की आवश्यकता होती है, तो JSON के साथ 200 वापस करें। यदि किसी रिप्रेजेंटेशन की आवश्यकता नहीं है, तो 204 मान्य है और ETag अभी भी मेटाडेटा ले जा सकता है।
• यदि अनुरोध स्वीकार कर लिया गया है लेकिन कार्य जारी है, तो इसे 204 के रूप में छिपाने के बजाय टास्क-स्टेटस लिंक के साथ 202 वापस करें।

HTTP/1.1 204 No Content
ETag: "user-42-v7"
Cache-Control: no-store

HTTP/1.1 200 OK
Content-Type: application/json

[]

RFC 9110 204 को बिना मैसेज कंटेंट के रूप में परिभाषित करता है, इसलिए क्लाइंट, प्रॉक्सी और टेस्ट को बॉडी की अनुपस्थिति को कॉन्ट्रैक्ट के हिस्से के रूप में मानना चाहिए। केवल एकरूपता के लिए सफल 200 के अंदर व्यावसायिक त्रुटियां न डालें, और कुछ बाइट्स बचाने के लिए प्रत्येक खाली परिणाम को 204 में न बदलें।

विकल्प और ट्रेड-ऑफ

एक रिक्त-ऐरे 200 प्रकारों को स्थिर रखता है, जेनरेट किए गए SDKs के लिए आसान है, और पेजिनेशन मेटाडेटा ले जा सकता है; इसमें कुछ बाइट्स की लागत आती है। 204 बिना किसी रिप्रेजेंटेशन के सफलता को स्पष्ट रूप से व्यक्त करता है, जो DELETE या ऐसे अपडेट के लिए उपयुक्त है जो डेटा को प्रतिध्वनित नहीं करता है; क्लाइंट्स को अनुपस्थित बॉडी को संभालना होगा और वे वहां त्रुटि विवरण नहीं पढ़ सकते हैं। एक मान्य रिक्त कलेक्शन के बजाय अनुपलब्ध टारगेट रिसोर्स के लिए 404 आरक्षित रखें।

विफलता मोड, सीमाएं और विरोधी उदाहरण

• रिक्त GET सूची के लिए 204 लौटाने से क्लाइंट एक मान्य रिक्त परिणाम को एक अलग प्रतिक्रिया प्रकार के रूप में मानते हैं, जिससे पेजिनेशन और जेनेरिक डिकोडिंग टूट जाती है।
• 204 के साथ JSON बॉडी भेजना इसके मैसेज सेमांटिक्स का उल्लंघन करता है; प्रॉक्सी इसे हटा सकते हैं और क्लाइंट अलग व्यवहार करेंगे।
• Idempotency को दस्तावेज़ित किए बिना पहले DELETE पर 204 और पुन: प्रयास पर 404 लौटाने से परिहार्य पुन: प्रयास त्रुटियां उत्पन्न होती हैं।
• { "error": ... } के साथ 200 लौटाने से मॉनिटरिंग और SDKs व्यावसायिक विफलता को सफलता के रूप में वर्गीकृत करते हैं।
• ऐसे अपडेट के बाद 204 लौटाना जिसमें नए ETag की आवश्यकता है लेकिन रिस्पॉन्स हेडर छोड़ दिया गया है, सुरक्षित कैशिंग या समवर्ती नियंत्रण को रोकता है।

परीक्षण और सत्यापन चेकलिस्ट

प्रत्येक एंडपॉइंट पर स्टेटस, बॉडी, Content-Type, ETag और कैश हेडर के लिए कॉन्ट्रैक्ट टेस्ट लिखें। पहले और बार-बार किए गए DELETE, रिक्त कलेक्शन, अनुपलब्ध एकल रिसोर्स, रिप्रेजेंटेशन के साथ और बिना अपडेट, 202 एसिंक ब्रांच, प्रॉक्सी फ़ॉरवर्डिंग और SDK डिकोडिंग को कवर करें। OpenAPI से कम से कम एक क्लाइंट जेनरेट करें और सत्यापित करें कि 204 JSON पार्सिंग त्रुटियों को ट्रिगर नहीं करता है; जांचें कि मॉनिटरिंग 2xx, 404 और संरचित व्यावसायिक त्रुटियों को अलग करती है।

फॉलो-अप प्रश्न

क्या 204 एक ETag या अन्य रिस्पॉन्स हेडर ले जा सकता है?

हाँ। मैसेज कंटेंट को प्रतिबंधित करने का मतलब मेटाडेटा को प्रतिबंधित करना नहीं है। ETag, कैश नियंत्रण या trace ID समवर्ती नियंत्रण और निदान का समर्थन कर सकते हैं, लेकिन यह दस्तावेज़ित करें कि वे कब मौजूद हैं।

क्या एक खाली पेज 200 होना चाहिए या 204?

यदि रिप्रेजेंटेशन एक सूची है, तो रिक्त ऐरे और पेजिनेशन मेटाडेटा के साथ 200 को प्राथमिकता दें। 204 पर केवल तभी विचार करें जब "बिना रिप्रेजेंटेशन के सफलता" स्पष्ट हो और प्रत्येक क्लाइंट अनुपस्थित बॉडी को संभालता हो।

क्या रिसोर्स के गायब होने पर DELETE को 404 वापस करना चाहिए?

हमेशा नहीं। यदि डिलीट करने का अर्थ है "यह सुनिश्चित करना कि रिसोर्स अनुपस्थित है," तो दोहराए गए अनुरोध 204 लौटा सकते हैं। यदि कॉल करने वालों को यह जानने की आवश्यकता है कि क्या यह मौजूद था, तो 404 लौटाएं। दस्तावेज़ों, SDKs और मॉनिटरिंग में इस विकल्प को सुसंगत रूप से रिकॉर्ड करें।