HTTP PUT अनुरोध में 'पूरे' राज्य का प्रतिनिधित्व क्यों होना चाहिए और केवल आंशिक नहीं हो सकता है?आंशिक पुट को अस्वीकार करने के पीछे क्या औचित्य है?
मैं समझता हूं कि यह पुट की मौजूदा परिभाषा है - यह प्रश्न कारणों के बारे में है कि इसे इस तरह परिभाषित किया जाएगा।
यानी:
आंशिक डालता रोकने के द्वारा क्या फायदा हुआ है?
बेवकूफ आंशिक अद्यतनों को क्यों रोक रहा था स्वीकार्य हानि माना जाता है?
पुट का अर्थ है कि HTTP spec इसका अर्थ क्या परिभाषित करता है। ग्राहक और सर्वर उस अर्थ को नहीं बदल सकते हैं। यदि ग्राहक या सर्वर अपनी परिभाषा के विपरीत PUT का उपयोग करते हैं, तो कम से कम निम्न चीज़ें हो सकती हैं:
Put परिभाषा idempotent द्वारा है। इसका मतलब है कि एक ग्राहक (या मध्यस्थ!) किसी भी समय पुट दोहरा सकता है और यह सुनिश्चित कर लें कि प्रभाव वही होगा। मान लीजिए कि मध्यस्थ को क्लाइंट से पुट अनुरोध प्राप्त होता है। जब यह सर्वर के अनुरोध को आगे बढ़ाता है, तो नेटवर्क समस्या होती है। मध्यस्थ परिभाषा के अनुसार जानता है कि यह सफल होने तक PUT को पुनः प्रयास कर सकता है। यदि सर्वर एक गैर-बेवकूफ तरीके से PUT का उपयोग करता है तो इन संभावित एकाधिक कॉलों का अवांछित प्रभाव होगा।
यदि आप आंशिक अद्यतन करना चाहते हैं, तो पैच का उपयोग करें या उप-संसाधन पर POST का उपयोग करें और 303 वापस 'मुख्य' संसाधन को देखें, उदा।
POST /account/445/owner/address
Content-Type: application/x-www-form-urlencoded
street=MyWay&zip=22222&city=Manchaster
303 See Other
Location: /account/445
संपादित करें: सामान्य प्रश्न क्यों आंशिक अपडेट idempotent नहीं किया जा सकता पर:
एक आंशिक अद्यतन सामान्य रूप में idempotent नहीं जा सकता क्योंकि idempotency मीडिया प्रकार अर्थ विज्ञान पर निर्भर करता है। आईओओ, आप एक प्रारूप निर्दिष्ट करने में सक्षम हो सकते हैं जो बेवकूफ पैच की अनुमति देता है, लेकिन प्रत्येक मामले के लिए पैच को बेवकूफ होने की गारंटी नहीं दी जा सकती है। चूंकि किसी विधि के अर्थशास्त्र मीडिया प्रकार का कार्य नहीं हो सकता है (ऑर्थोगोनलिटी कारणों के लिए) पैच को गैर-बेवकूफ के रूप में परिभाषित करने की आवश्यकता है। और PUT (idempotent के रूप में परिभाषित किया जा रहा है) आंशिक अद्यतन के लिए उपयोग नहीं किया जा सकता है।
हाय जान, जैसा कि मैंने पहले ही कहा था; "मैं समझता हूं कि यह पुट की मौजूदा परिभाषा है - यह सवाल कारणों के बारे में है कि इसे इस तरह परिभाषित किया जाएगा"। दूसरे अनुच्छेद में आपका उदाहरण यह दर्शाता है कि आंशिक अद्यतन गैर-बेवकूफ है - जाहिर है यह पैच के लिए है। मुझे * idempotent * आंशिक अद्यतनों में दिलचस्पी है - यानी आंशिक पुट। – Mike
पैच फिर से जोड़ा जा रहा है। इसके अलावा, जनवरी - idempotency प्रोटोकॉल में अपनी परिभाषा के संबंध में मीडिया प्रकार के किसी भी विशिष्ट सेट पर निर्भर करने की आवश्यकता नहीं है, एक विधि के अर्थशास्त्र एक समान इंटरफ़ेस के हिस्से के रूप में इसकी परिभाषा का एक कार्य है .. मैं अभी भी संघर्ष कर रहा हूँ पीयूटी की परिभाषा को 'राज्य का एक बेवकूफ परिवर्तन' (यानी वह जो आंशिक रूप से नहीं रोकता) के रूप में सरल कुछ बदलकर वास्तव में खो गया है। – Mike
@ माइक, जैसा कि मैंने उपरोक्त व्याख्या करने की कोशिश की है: आप विशेष मीडिया प्रकार को ध्यान में रखे बिना आंशिक अद्यतन को निष्क्रिय नहीं कर सकते हैं। Idempotency उपयोग किए गए मीडिया प्रकार पर निर्भर करता है और चूंकि आप मीडिया प्रकार सेमेन्टिक्स पर निर्भर करने के लिए विधि अर्थशास्त्र को परिभाषित नहीं कर सकते हैं, इसलिए एक सामान्य प्रतिस्थापन के लिए एक अद्यतन केवल सामान्य स्थिति के लिए बेवकूफ हो सकता है। एक विधि जो आंशिक अद्यतन निर्दिष्ट करती है उसे गैर-idempotent परिभाषित किया जाना चाहिए। आईओओ, आप बस "राज्य के एक बेवकूफ परिवर्तन" को परिभाषित नहीं कर सकते हैं (यानी वह जो आंशिक को रोकता नहीं है) "। यह अपने आप में एक विरोधाभास है। –
क्योंकि, मुझे लगता है कि यह असंगत "विचार" में अनुवादित होगा जब कई समवर्ती ग्राहक राज्य तक पहुंच जाएंगे। जहां तक मैं बता सकता हूं कि आरईएसटी में "आंशिक दस्तावेज" अर्थशास्त्र नहीं है और संभवतः समवर्ती संदर्भ में उस अर्थशास्त्र से निपटने की जटिलता के मुकाबले इसे जोड़ने का लाभ प्रयास के लायक नहीं था।
यदि दस्तावेज़ बड़ा है, तो आपको कई स्वतंत्र दस्तावेज़ों को बनाने से रोकने के लिए कुछ भी नहीं है और एक अत्यधिक दस्तावेज है जो उन्हें एक साथ जोड़ता है। इसके अलावा, एक बार सभी बिट्स और टुकड़े एकत्र किए जाने के बाद, मुझे लगता है कि सर्वर पर एक नया दस्तावेज़ collated किया जा सकता है।
तो, इस पर विचार करने से कोई "सीमाएं" कर सकता है, मैं समझ सकता हूं कि इस सुविधा ने कट क्यों नहीं किया।
क्षमाप्रार्थी - मैं 'पूर्ण' बेवकूफ अद्यतनों से व्यवहार में भिन्न आंशिक बेवकूफ अपडेट द्वारा उत्पादित असंगत विचारों के बारे में बिंदु को समझ नहीं पा रहा हूं। प्रोटोकॉल परिभाषा बिंदु से जटिलता में सुझाए गए वृद्धि के रूप में भी मुझे अनिश्चितता है। – Mike
संक्षिप्त उत्तर: पुट ऑपरेशन की एसिडिटी और अद्यतन इकाई की स्थिति।
लांग जवाब:
RFC 2616: पैरा 2.5, "POST विधि संलग्न इकाई अनुरोध किया गया URL की एक नई अधीनस्थ के रूप में स्वीकार किए जाने का अनुरोध"। अनुच्छेद 2.6, "पुट विधि निर्दिष्ट इकाई पर संलग्न इकाई को संग्रहीत करने का अनुरोध करती है"।
हर बार जब आप पोस्ट निष्पादित करते हैं, अर्थात् सर्वर पर एक नया इकाई उदाहरण बनाना है, पोस्ट एक एसीआईडी ऑपरेशन का गठन करता है। लेकिन शरीर में एक ही इकाई के साथ दो बार एक ही पोस्ट दोहराया जा सकता है, फिर भी परिणामस्वरूप अलग-अलग परिणाम हो सकते हैं, उदाहरण के लिए सर्वर नए इंस्टॉलेशन को स्टोर करने के लिए स्टोरेज से बाहर चला गया है - इस प्रकार, POST बेवकूफ नहीं है।
दूसरी तरफ एक मौजूदा इकाई को अद्यतन करने का अर्थपूर्ण है। इस बात की कोई गारंटी नहीं है कि भले ही आंशिक अद्यतन बेवकूफ है, यह भी एसीआईडी है और इसके परिणामस्वरूप लगातार और वैध इकाई स्थिति होती है। इस प्रकार, एसिडिटी सुनिश्चित करने के लिए, अर्थपूर्ण को पूर्ण इकाई को भेजने की आवश्यकता है। यहां तक कि यदि यह HTTP प्रोटोकॉल लेखकों के लिए एक लक्ष्य नहीं था, तो PUT अनुरोध की idempotency ACID को लागू करने के प्रयास के दुष्प्रभाव के रूप में होगा।
बेशक, यदि HTTP सर्वर के पास संस्थाओं के अर्थशास्त्र का नज़दीकी ज्ञान है, तो यह आंशिक PUTs को अनुमति दे सकता है, क्योंकि यह सर्वर-साइड तर्क के माध्यम से इकाई की स्थिरता सुनिश्चित कर सकता है। हालांकि डेटा और सर्वर के बीच तंग युग्मन की आवश्यकता है।
"इस बात की कोई गारंटी नहीं है कि अगर आंशिक अद्यतन बेवकूफ है, तो यह भी परमाणु है" - हम्म, मुझे यह समझ में नहीं आता है। एक बेवकूफ अद्यतन गैर-परमाणु कैसे हो सकता है? – Mike
जब मैंने परमाणुता कहा तो मैंने एसिडनेस को बताया। दूसरे शब्दों में, यदि मैं इसके अंत में इकाई वैध और सुसंगत स्थिति में हूं, तो मैं एक ऑपरेशन "परमाणु" मानता हूं। एटीआईडी को परमाणु के बजाय स्पष्ट रूप से इस्तेमाल किया जाना चाहिए था। –
एक पूर्ण दस्तावेज़ अद्यतन के साथ, यह स्पष्ट है कि, विशेष एपीआई के किसी भी विवरण के बिना या दस्तावेज़ संरचना पर इसकी सीमाएं क्या हैं, परिणामस्वरूप दस्तावेज़ अद्यतन के बाद क्या होगा।
यदि कोई निश्चित विधि आंशिक सामग्री अद्यतन कभी नहीं जानी जाती है, और एक एपीआई जिसने केवल उस विधि का समर्थन किया है, तो यह हमेशा स्पष्ट होगा कि किसी को एपीआई का उपयोग करने वाले व्यक्ति को दस्तावेज़ बदलने के लिए क्या करना होगा वैध सामग्री का दिया सेट।
इस मुद्दे के बारे में एक और चर्चा के लिए यहां देखें: http://tech.groups.yahoo.com/group/rest-discuss/message/17415 - मैंने इसे सब पढ़ लिया है और परिभाषा के लिए कोई अनिवार्य कारण नहीं देखा है केवल पूर्ण अपडेट के लिए हो रहा है। – lkraider
@lkraider मैं सहमत हूं। मुझे कुछ करने के अलावा कोई लाभ नहीं दिखता क्योंकि HTTP स्पेक पुट और पैच (जो बहुत व्यावहारिक नहीं है) के बीच एक भिन्नता बनाता है। – Brenden