पुट बनाम पैच

दोनों विधियाँ मौजूदा संसाधन को संशोधित करती हैं, और इनमें बॉडी के अर्थ में अंतर होता है। PUT बॉडी पूरी तरह से नई स्थिति होती है: जिन फ़ील्ड्स को आप छोड़ देते हैं, वे सिद्धांत रूप में हटा दिए जाते हैं या रीसेट कर दिए जाते हैं। PATCH बॉडी परिवर्तनों का विवरण होती है, जिसे सर्वर दस्तावेज़ित प्रारूप में प्रस्तुत करता है — एक आंशिक ऑब्जेक्ट, या JSON Patch की तरह ऑपरेशनों की सूची।

यह काम किस प्रकार करता है

परिभाषा के अनुसार PUT प्रक्रिया में एकरूपता होती है: एक ही पूर्ण निरूपण को दो बार भेजने पर परिणाम एक ही रहता है। PATCH प्रक्रिया में यह गारंटी नहीं है, क्योंकि "append to this list" या "increment" जैसी क्रिया को दो बार करने पर एक बार करने से अलग परिणाम मिलता है। यही कारण है कि PATCH अनुरोधों को विशेष रूप से If-Match से लाभ होता है, जिससे पुनः प्रयास किए गए PATCH अनुरोध को दो बार भेजने के बजाय अस्वीकार किया जा सकता है।

गलत धारणा

वह PATCH असल में "PUT without the fields you did not change" । कई API इसे इसी तरह लागू करते हैं, लेकिन मेथड में ऐसा कुछ नहीं लिखा होता — मर्ज-स्टाइल PATCH और JSON Patch डॉक्यूमेंट दोनों ही PATCH हैं, लेकिन उनके अर्थ बहुत अलग हैं। और व्यवहार में कई "PUT" एंडपॉइंट्स रिप्लेस करने के बजाय मर्ज करते हैं, इसलिए जांच लें कि आपके एंडपॉइंट में कोई फ़ील्ड न होने पर क्या होता है।

इसे यहाँ आजमाएँ

पिज़्ज़ा एपीआई PATCH /pizza/v1/orders/{id} पर आंशिक अपडेट लेता है, और प्रोटोकॉल लैब PATCH /protocol/v1/documents/{id} पर RFC 6902 JSON पैच स्वीकार करता है; कैरेक्टर PUT एंडपॉइंट्स If-Match को बदलते और जाँचते हैं।

संबंधित

• What JSON Patch is
• सुरक्षित और स्थिर विधियाँ

स्रोत

• HTTP semantics — RFC 9110
• HTTP caching — RFC 9111

अन्य शब्द

• JSON पैच — JSON दस्तावेज़ में परिवर्तनों को संक्रियाओं की सूची के रूप में वर्णित करने के लिए एक मानक प्रारूप (RFC 6902)।
• सुरक्षित और स्थिर विधियाँ — HTTP विधियों के दो स्वतंत्र गुण जो यह निर्धारित करते हैं कि क्लाइंट को क्या पुनः प्रयास करने की अनुमति है।
• ETag — किसी प्रस्तुति के लिए एक अपारदर्शी संस्करण पहचानकर्ता, जिसका उपयोग इसे दोबारा भेजने से बचने और परस्पर विरोधी लेखन का पता लगाने के लिए किया जाता है।
• पुनः प्रयास-बाद — एक रिस्पॉन्स हेडर जो क्लाइंट को बताता है कि दोबारा कोशिश करने से पहले उसे कितना इंतजार करना है, यह सेकंड में या तारीख के रूप में बताया जा सकता है।
• घातीय बैकऑफ़ — एक ऐसी पुनःप्रयास रणनीति जिसमें प्रत्येक प्रतीक्षा पिछली प्रतीक्षा से लंबी होती है, और इसमें यादृच्छिकता जोड़ी जाती है ताकि ग्राहक एक साथ पुनःप्रयास न करें।
• ब्रेक का अनुरोध — अनुरोध को रद्द करने से पहले ग्राहक द्वारा प्रतिक्रिया की प्रतीक्षा करने का अधिकतम समय।

यह पृष्ठ अंग्रेज़ी में पढ़ें

सभी शब्द · परीक्षण तकनीकें · सभी 39 मॉक REST API

आखरी अपडेट 16 अक्टूबर 2026