यह कल्पना की जा सकती है कि एक अन्य ग्राहक ने अंतरिम में संसाधन के अन्य पहलुओं को भी संशोधित किया। बैंडविड्थ ओवरहेड के बावजूद, PUT के जवाब में हमेशा पूर्ण प्रतिनिधित्व शामिल करना सबसे अच्छा अभ्यास है?आरईएसटी में, क्या मुझे पुट के जवाब में प्रतिनिधित्व वापस करना चाहिए?
जेल्डुपॉन्ट की टिप्पणी ने मुझे सही दिशा में इंगित किया। अगर ई-मेल हेडर, as described here का उपयोग कर सशर्त पुट करके संसाधन को संशोधित किया गया है, तो यह निर्धारित करने के लिए ईटैग का उपयोग करेगा।
फिर, किसी संघर्ष के मामले में, मैं उपयोगकर्ता को यह तय करने दूंगा कि सर्वर से नवीनतम प्रतिनिधित्व प्राप्त करना है या नहीं, अपने आप में परिवर्तनों को ओवरराइट करना है या नहीं।
इस प्रकार, संघर्ष पहचान और संकल्प में सहायता के लिए PUT के जवाब में पूर्ण प्रतिनिधित्व वापस करने की आवश्यकता नहीं है।
मुझे लगता है कि एक जोड़ी होने और प्राप्त करने के बारे में सोचना पसंद है - वे केवल एक आईडी लेते हैं।
पोस्ट और पुट एक जोड़ी की तरह लग रहा है। वे एक धारावाहिक वस्तु लेते हैं और इसे लगातार बनाते हैं। नतीजतन, मुझे लगता है कि POST और PUT दोनों को परिणामस्वरूप ऑब्जेक्ट को बनाया जाना चाहिए।
कुछ मामलों में, आप दृढ़ता के हिस्से के रूप में अतिरिक्त गणना कर सकते हैं, और PUT उन गणना परिणामों को प्रतिबिंबित कर सकता है। तकनीकी रूप से, यह एक सामान्य सामान्य रूप उल्लंघन हो सकता है क्योंकि आपने मूल्य प्राप्त किए हैं। लेकिन अक्सर, वेब सेवा का पूरा बिंदु POST और संभवतः PUT के हिस्से के रूप में कुछ मूल्य-जोड़ गणना करना है।
मैं आपके दर्शन की सराहना करता हूं, लेकिन असहमत (कम से कम आंशिक रूप से)। HTTP spec (जैसा कि यह GET के लिए करता है) को केवल एक यूआरएल को हटाने/प्रतिबंधित/सीमित करने की आवश्यकता नहीं है।सबसे महत्वपूर्ण बात यह है कि आप एकमात्र ऐसा नहीं हैं जो सोचता है कि यह मामला है (और सबसे महत्वपूर्ण बात यह है कि टैलएंड जैसी प्रमुख सॉफ्टवेयर परियोजनाएं इस धारणा के आसपास डिजाइन की गई हैं।) एकल इकाइयों के लिए अनुरोधों को हटाने के लिए शरीर की आवश्यकता नहीं है (जैसे जीईटी) , लेकिन संग्रह के लिए अनुरोध हटाएं कुछ डेटा के बिना अविश्वसनीय रूप से कठोर हैं जो अनुरोध को परिशोधित करता है – Anthony
कई (यदि अधिकतर नहीं) मामलों में, सर्वर संसाधन में कुछ जोड़ देगा भले ही इसे PUT के माध्यम से बनाया या अपडेट किया गया हो। उदाहरण टाइमस्टैम्प, एक संस्करण संख्या, या दूसरों से गणना की गई कोई तत्व हैं। यह सच है भले ही आप रीस्टफुल दृष्टिकोण का पालन करें और आंशिक अपडेट के लिए PUT का उपयोग न करें।
अकेले इस कारण से, अद्यतन या निर्मित संसाधन के प्रतिनिधित्व को वापस करना अक्सर पुट अनुरोधों के लिए एक अच्छा विचार है। मैं जरूरी नहीं कि इसे "सर्वश्रेष्ठ अभ्यास" कहें, हालांकि - यदि आप एक विशाल 2 जीबी छवि फ़ाइल डालते हैं तो शायद आप प्रतिक्रिया के हिस्से के रूप में इसे वापस नहीं करना चाहते हैं।
दूसरी ओर, ईटाग समेत, निश्चित रूप से "सर्वोत्तम अभ्यास" स्थिति का हकदार है।
आप प्रतिक्रिया Location हेडर सेट के साथ अद्यतन संसाधन (Post/Redirect/Get) के यूआरआई पर सेट करने पर विचार करना चाहेंगे। इस तरह क्लाइंट को संसाधन की वर्तमान स्थिति प्राप्त होती है (यदि यह Location शीर्षलेख का पालन करना चुनता है) भले ही इसे अंतरिम में संपादित किया गया हो, और ब्राउज़र का उपयोग करते हुए अनुरोध को पुनः सबमिट करने का खतरा नहीं है।
हालांकि, यह पैटर्न उचित सफलता कोड (200 OK, 202 Accepted इत्यादि) भेजने से रोकता है जो क्लाइंट के लिए उपयोगी हो सकता है। इसके अलावा, आरईएसटी की आपकी परिभाषा के आधार पर, आप इसे गैर-मानक अभ्यास मान सकते हैं।
यदि संभवतः क्लाइंट लोगों द्वारा संचालित ब्राउज़र होने की संभावना है तो यह अधिक उपयुक्त है।
लेनदेन से जुड़े एक अद्वितीय पहचानकर्ता को वापस करना बेहतर होगा? बैंडविड्थ पर बचाता है और यह सुनिश्चित करने के लिए कि अंतरिम में कुछ भी नहीं हुआ है, वैसे भी सर्वर पर वापस लौटने की संभावना है। अर्थात। यदि आप डेटा वापस करते हैं, तो यह किसी भी तरह से पुराना हो सकता है। – jldupont
यह बेहोशी है ... मैं खुद से यह पूछ रहा था कि 20 मिनट पहले ... – skaffman