बैकएंड इंटरव्यू: आपको PUT बनाम PATCH का उपयोग कब करना चाहिए?

प्रॉम्प्ट और संदर्भ

आप एक टीम-प्रोफ़ाइल API के ओनर हैं। क्लाइंट केवल displayName बदल सकता है या एक पूरी प्रोफ़ाइल सबमिट कर सकता है, और मोबाइल से रिट्राय होना आम बात है। बताएं कि PUT या PATCH का उपयोग कब करना है, छोड़े गए फ़ील्ड और null को कैसे परिभाषित करना है, और टकरावों (conflicts), एटॉमिसीटी, आइडेम्पोटेंट रिट्राय और कम्पैटिबिलिटी को कैसे संभालना है।

Greenroom की 2026 बैकएंड इंटरव्यू सूची में PUT और PATCH के बीच अंतर, आइडेम्पोटेंसी और मेथड के चयन को स्पष्ट रूप से शामिल किया गया है। RFC 5789 PUT एंटिटी को रिसोर्स के एक नए पूर्ण प्रतिनिधित्व (representation) के रूप में परिभाषित करता है, जबकि PATCH एंटिटी में वर्तमान रिसोर्स पर लागू करने के लिए निर्देश होते हैं। यह प्रश्न किसी विशिष्ट कंपनी से जुड़ा नहीं है।

इंटरव्यूअर्स क्या मूल्यांकन करते हैं

एक सामान्य उत्तर “PUT पूर्ण है, PATCH आंशिक है” को रट लेता है। एक मजबूत उत्तर रिसोर्स कॉन्ट्रैक्ट को परिभाषित करता है, यह बताता है कि छोड़े गए फ़ील्ड अपरिवर्तित रहते हैं या नहीं, यह बताता है कि null किसी फ़ील्ड को साफ़ करता है या नहीं, If-Match की व्याख्या करता है, और यह बताता है कि क्या कोई विफल अनुरोध पूरे बदलाव को लागू किए बिना छोड़ देता है। फॉलो-अप आमतौर पर डुप्लिकेट अनुरोधों, खोए हुए रिस्पॉन्स, अज्ञात फ़ील्ड, ऑडिट इवेंट और पुराने क्लाइंट्स को कवर करते हैं।

मुख्य संकेत PATCH को केवल एक छोटा PUT मानने के बजाय HTTP सिमेंटिक्स को डेटाबेस अपडेट और कॉनकरेंसी कंट्रोल से जोड़ना है।

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

क्या PUT रिसोर्स बना सकता है? यह प्रॉम्प्ट किसी मौजूदा प्रोफ़ाइल को अपडेट करता है; यदि एक स्थिर URI पर निर्माण की अनुमति है, तो स्वामित्व और डुप्लिकेट-अनुरोध व्यवहार को परिभाषित करें।
क्या क्लाइंट एक पूर्ण रिसोर्स भेजता है या एक चेंज डॉक्यूमेंट? पूर्ण प्रतिनिधित्व के लिए PUT का उपयोग करें और फ़ील्ड संचालन या आंशिक प्रतिनिधित्व के लिए PATCH का उपयोग करें।
छूट (omission) और null का क्या अर्थ है? यहाँ छूट मान को सुरक्षित रखती है और null नलेबल फ़ील्ड को साफ़ करता है; नॉन-नलेबल फ़ील्ड इसे अस्वीकार कर देते हैं।
क्या समवर्ती (concurrent) अपडेट एक-दूसरे को ओवरराइट कर सकते हैं? यह प्रॉम्प्ट साइलेंट ओवरराइट को अस्वीकार करता है और इसके लिए ETag/If-Match या डेटाबेस वर्ज़न स्थिति की आवश्यकता होती है।
क्या कोई साइड इफेक्ट्स हैं? खोज इंडेक्सिंग, ऑडिट इवेंट और नोटिफिकेशन को कमिट की गई स्थिति का पालन करना चाहिए; एसिंक्रोनस प्रभाव HTTP एटॉमिसीटी का हिस्सा नहीं हैं।

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

“मैं PUT को उन क्लाइंट्स के लिए एक रिसोर्स को पूर्ण प्रतिनिधित्व के साथ बदलने के रूप में परिभाषित करता हूँ जिनके पास पूरा स्नैपशॉट है। PATCH आंशिक परिवर्तनों को वहन करता है जैसे कि displayName अपडेट। PATCH को चूक बनाम null को परिभाषित करना चाहिए और पुराने फॉर्म को नए डेटा को ओवरराइट करने की अनुमति देने के बजाय पुराने वर्ज़न को अस्वीकार करना चाहिए। सर्वर पूरे दस्तावेज़ को मान्य करता है और इसे एक डेटाबेस लेनदेन में एटॉमिक रूप से लागू करता है, फिर एक वर्ज़न वाला एसिंक्रोनस इवेंट उत्सर्जित करता है। क्लाइंट समान अनुरोध सिमेंटिक्स और If-Match के साथ पुनः प्रयास करते हैं। यदि परिवर्तन रिसोर्स अपडेट के बजाय कोई कमांड है, तो मैं PATCH को ओवरलोड करने के बजाय एक एक्शन एंडपॉइंट का उपयोग करता हूँ।”

चरण-दर-चरण उत्तर

चरण 1: दोनों विधियों को रिसोर्स कॉन्ट्रैक्ट के रूप में लिखें

आयाम	PUT	PATCH
अनुरोध का अर्थ	बॉडी रिसोर्स का नया पूर्ण प्रतिनिधित्व है	बॉडी एक परिवर्तन निर्देश या आंशिक प्रतिनिधित्व है जिसे वर्तमान रिसोर्स पर लागू किया गया है
छोड़ा गया फ़ील्ड	आमतौर पर इसका मतलब है कि क्लाइंट ने पूर्ण स्थिति की आपूर्ति की है; इसे चुपचाप पुराने फ़ील्ड को संरक्षित नहीं करना चाहिए	स्पष्ट रूप से इसका अर्थ संरक्षित या अमान्य होना चाहिए
आइडेम्पोटेंसी	उसी प्रतिनिधित्व को दोहराने से उसी रिसोर्स स्थिति तक पहुँचना चाहिए	विधि द्वारा गारंटीकृत नहीं है, लेकिन एक विशिष्ट पैच दस्तावेज़ आइडेम्पोटेंट हो सकता है
विशिष्ट उपयोग	एक पूर्ण संपादक स्नैपशॉट को सिंक करें या कॉन्फ़िगरेशन को बदलें	JSON Merge Patch या JSON Patch के साथ एक फ़ील्ड बदलें

PUT की मुख्य विशेषता बॉडी का आकार नहीं है; यह क्लाइंट का दावा है कि प्रतिनिधित्व पूर्ण है। यदि कोई क्लाइंट केवल कुछ फ़ील्ड जानता है लेकिन PUT भेजता है, तो सर्वर अनुपलब्ध फ़ील्ड को विलोपन या डिफ़ॉल्ट के रूप में व्याख्या कर सकता है। PATCH अपने आप सुरक्षित नहीं है: सत्यापन, प्राधिकरण और साइड इफेक्ट्स अभी भी लागू होते हैं।

चरण 2: PATCH दस्तावेज़ और तीन फ़ील्ड स्थितियों को परिभाषित करें

http

PATCH /v1/teams/t_123/profile HTTP/1.1
Content-Type: application/merge-patch+json
If-Match: "profile-v17"

{"displayName":"Design Platform","avatarUrl":null}

यह प्रॉम्प्ट JSON Merge Patch शैली का उपयोग करता है: displayName को बदल दिया जाता है, avatarUrl: null एक नलेबल फ़ील्ड को साफ़ करता है, और छोड़ा गया फ़ील्ड अपरिवर्तित रहता है। यदि व्यवसाय को तत्व-स्तरीय ऐरे संचालन, स्थानांतरण या परीक्षण की आवश्यकता है, तो इसके बजाय एक सीमित JSON Patch ऑपरेशन सूची का उपयोग करें।

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

चरण 3: वर्ज़न शर्त के साथ साइलेंट ओवरराइट को रोकें

http

GET /v1/teams/t_123/profile HTTP/1.1

ETag: "profile-v17"

PATCH /v1/teams/t_123/profile HTTP/1.1
If-Match: "profile-v17"
Content-Type: application/merge-patch+json

{"displayName":"Design Platform"}

डेटाबेस अपडेट में एक वर्ज़न प्रेडिकेट होता है: केवल वर्ज़न 17 ही लिख सकता है और 18 पर आगे बढ़ सकता है। बेमेल होने पर 412 Precondition Failed वापस आता है; क्लाइंट फिर से पढ़ता है, टकराव दिखाता है, या अपने पैच को पुनर्जीवित करता है। यह नए डेटा पर पुराने वर्ज़न को बाध्य नहीं कर सकता। यदि If-Match अनिवार्य है और गायब है, तो 428 Precondition Required कॉनकरेंसी नीति को स्पष्ट कर सकता है।

PATCH को एक दस्तावेज़ के रूप में भी एटॉमिक होना चाहिए: फ़ील्ड A का सफल होना जबकि फ़ील्ड B का विफल होना एक स्वीकार्य आधा-अपडेट नहीं है। लेनदेन, सत्यापन चरण और विशिष्ट बाधाएं तय करती हैं कि परिवर्तन कमिट होता है या नहीं। साइड-इफेक्ट इवेंट को एक आउटबॉक्स में लिखा जाना चाहिए और रिसोर्स वर्ज़न के साथ कमिट के बाद प्रकाशित किया जाना चाहिए।

चरण 4: डुप्लिकेट अनुरोधों और अज्ञात परिणामों को संभालें

समान पूर्ण प्रतिनिधित्व वाले बार-बार PUT अनुरोध एक ही स्थिति में परिवर्तित होते हैं। PATCH में वह गुण केवल तभी होता है जब ऑपरेशन दोहराने योग्य हो: displayName सेट करना आइडेम्पोटेंट है, जबकि increment seats by 1 नहीं है। एक गैर-आइडेम्पोटेंट PATCH को एक अनुरोध ID, एक वर्ज़न शर्त, या एक ऐसे ऑपरेशन की आवश्यकता होती है जो लक्ष्य स्थिति को व्यक्त करता हो।

नेटवर्क विफलता के बाद, क्लाइंट को यह नहीं पता होता है कि सर्वर ने कमिट किया है या नहीं। रिकॉर्ड किए गए फ़िंगरप्रिंट और परिणाम के साथ एक स्थिर अनुरोध ID का उपयोग करें, या If-Match और एक लक्ष्य स्थिति के साथ पुनः प्रयास करें। साइड इफेक्ट जोड़ने वाले पैच को आँख बंद करके दोबारा न चलाएं। रिसोर्स कमिट होने के बाद, इवेंट उपभोक्ता इंडेक्सिंग और नोटिफिकेशन को संभालते हैं और इवेंट ID द्वारा डिडुप्लिकेट करते हैं।

चरण 5: तय करें कि PUT/PATCH कब गलत आकार है

“प्रोफ़ाइल प्रकाशित करें”, “अनुमतियों की पुनर्गणना करें”, और “निमंत्रण भेजें” कमांड हैं, प्रतिस्थापन या आंशिक रिसोर्स प्रतिनिधित्व नहीं। POST /profile:publish जैसा एक एक्शन एंडपॉइंट अनुमतियों, ऑडिट, रिट्राय और एसिंक्रोनस स्थिति को अधिक स्पष्ट रूप से व्यक्त करता है। PATCH के आकार का कमांड क्लाइंट्स को डुप्लिकेट निष्पादन और साइड इफेक्ट्स को गलत समझने पर मजबूर करता है।

उच्च विवाद (contention) या क्रॉस-रिसोर्स लेनदेन के लिए डोमेन कमांड की भी आवश्यकता हो सकती है। किसी सदस्य को संपादक से मालिक में बदलने के लिए कोटा और ऑडिट जांच की आवश्यकता होती है; PATCH के साथ एक स्ट्रिंग को बदलना उन इनवेरिएंट्स को व्यक्त नहीं करता है।

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

“मैं अलग-अलग अनुबंधों के साथ PUT और PATCH दोनों को प्रदर्शित करूँगा। PUT एक पूर्ण टीम-प्रोफ़ाइल प्रतिनिधित्व स्वीकार करता है; एक छोड़ा गया फ़ील्ड एक अनुबंध त्रुटि या एक स्पष्ट डिफ़ॉल्ट है, कभी भी आकस्मिक रूप से ‘अपरिवर्तित छोड़ना’ नहीं है। PATCH एक प्रतिबंधित Merge Patch और केवल अनुमति प्राप्त फ़ील्ड स्वीकार करता है; चूक एक मान को सुरक्षित रखती है और null इसे केवल तभी साफ़ करता है जब फ़ील्ड नलेबल हो।

“दोनों विधियाँ ETag और If-Match का उपयोग करती हैं। डेटाबेस एक वर्ज़न-सशर्त अपडेट करता है और बेमेल होने पर 412 लौटाता है, इसलिए एक पुराना क्लाइंट नए डेटा को ओवरराइट नहीं कर सकता है। PATCH दस्तावेज़ को पूरी तरह से मान्य किया जाता है और एक लेनदेन में लागू किया जाता है; एक आउटबॉक्स कमिट के बाद एक वर्ज़न वाला इंडेक्सिंग इवेंट प्रकाशित करता है। एक सेट-फ़ील्ड PATCH आइडेम्पोटेंट हो सकता है; वेतन वृद्धि के लिए एक अनुरोध ID, एक शर्त, या एक लक्ष्य-स्थिति ऑपरेशन की आवश्यकता होती है। प्रकाशित करना और आमंत्रित करना POST क्रियाएं हैं क्योंकि उनके स्पष्ट साइड इफेक्ट्स हैं। मैं डुप्लिकेट, खोए हुए रिस्पॉन्स, चूक/null, टकराव, अज्ञात फ़ील्ड, आंशिक विफलताओं और पुराने-क्लाइंट कम्पैटिबिलिटी का परीक्षण करूँगा।”

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

लक्षण → PUT को “किसी भी फ़ील्ड को अपडेट करना” कहना → यह विफल क्यों होता है → कॉलर यह नहीं जान सकते कि छोड़े गए फ़ील्ड गायब हो जाते हैं या नहीं → सुधार → PUT को एक पूर्ण प्रतिनिधित्व बनाएं और आंशिक परिवर्तनों के लिए PATCH का उपयोग करें।
लक्षण → यह दावा करना कि PATCH स्वाभाविक रूप से आइडेम्पोटेंट है → यह विफल क्यों होता है → RFC 5789 इसकी गारंटी नहीं देता है; बार-बार वेतन वृद्धि स्थिति बदलती है → सुधार → केवल लक्ष्य-स्थिति पैच को दोहराने योग्य बनाएं और अन्य कार्यों में शर्तें या डिडुप्लिकेशन जोड़ें।
लक्षण → मनमानी JSON कुंजियों को कॉलम में मैप करना → यह विफल क्यों होता है → फ़ील्ड प्राधिकरण, प्रकार सत्यापन और क्रॉस-फ़ील्ड इनवेरिएंट को दरकिनार कर दिया जाता है → सुधार → एक अनुमति सूची और स्पष्ट डोमेन सत्यापन का उपयोग करें।
लक्षण → वर्ज़न टकराव के बाद अंतिम लेखक को जीतने देना → यह विफल क्यों होता है → एक पुराना फॉर्म चुपचाप नए डेटा को ओवरराइट कर देता है → सुधार → If-Match और एक वर्ज़न प्रेडिकेट का उपयोग करें, टकराव पर 412 लौटाएं।
लक्षण → कमिट के बाद खोज सेवा को सिंक्रोनस रूप से कॉल करना → यह विफल क्यों होता है → खोया हुआ रिस्पॉन्स या प्रोसेस क्रैश रिसोर्स और इंडेक्स को विभाजित कर देता है → सुधार → लेनदेन में एक आउटबॉक्स लिखें और इवेंट-ID डिडुप्लिकेशन के साथ एसिंक्रोनस रूप से प्रकाशित करें।

फॉलो-अप और प्रतिक्रियाएं

क्या होगा यदि उत्पाद चाहता है कि छोड़े गए PATCH फ़ील्ड मानों को साफ़ कर दें?

यह PATCH को एक अन्य पूर्ण-प्रतिनिधित्व अनुबंध में बदल देता है और इसे PUT के साथ धुंधला कर देता है। PUT का उपयोग करें, या एक स्पष्ट रूप से नामित फ़ील्ड-सेट प्रतिस्थापन मीडिया प्रकार को परिभाषित करें; महत्वपूर्ण हिस्सा छोड़े गए फ़ील्ड के परिणाम को स्पष्ट करना है।

क्या होगा यदि दो क्लाइंट दोनों वर्ज़न 17 पढ़ते हैं और विभिन्न फ़ील्ड संपादित करते हैं?

डिफ़ॉल्ट रूप से 412 लौटाएं और क्लाइंट को मर्ज करने और पुनः प्रयास करने दें, क्योंकि सर्वर यह नहीं मान सकता कि संपादन स्वतंत्र हैं। फ़ील्ड-स्तरीय विलय केवल तभी सुरक्षित होता है जब डोमेन स्पष्ट रूप से इसकी अनुमति देता है और पैच में फ़ील्ड वर्ज़न या परीक्षण संचालन शामिल होते हैं।

क्या होगा यदि PATCH बिलिंग या नोटिफिकेशन को ट्रिगर करता है?

रिसोर्स अपडेट और साइड इफेक्ट को ऑडिट करने योग्य चरणों में अलग करें: रिसोर्स और आउटबॉक्स को एक साथ कमिट करें, फिर एक आइडेम्पोटेंट उपभोक्ता को इवेंट को प्रोसेस करने दें। यदि साइड इफेक्ट के लिए स्पष्ट उपयोगकर्ता इरादे की आवश्यकता है, तो इसे एसिंक्रोनस ऑपरेशन स्थिति के साथ एक अलग POST कमांड बनाएं।