REST प्रश्न: एक प्रतिनिधित्व PUT, एक अलग मिलता है?

Question

प्रश्न का संक्षिप्त संस्करण:
क्या किसी विशेष यूआरआई में "प्राप्त करें" उस यूआरआई को "पुट" से मेल खाने की ज़रूरत है?

मुझे नहीं लगता। यहां बताया गया है:

यह देखते हुए कि एक संसाधन एक अमूर्त चीज है जो क्लाइंट द्वारा सैद्धांतिक रूप से अज्ञात है, जब हम एक पुट करते हैं, तो हमें केवल एक प्रतिनिधित्व भेजना होगा। आरएफसी 2616 पर गठबंधन के आधार पर, यह पूरी तरह से निर्दिष्ट नहीं है कि इसका अर्थ संसाधन के लिए क्या है जिसमें कई (संभावित रूप से अनंत?) प्रतिनिधित्व हैं, लेकिन यहां मेरे विचार हैं; कृपया मुझे बताएं कि क्या आप सहमत हैं:

मेरी उम्मीद यह है कि यदि मैं किसी संसाधन को प्रस्तुत करता हूं, तो उस यूआरआई में संसाधन के अन्य सभी प्रस्तुतिकरणों को आवश्यक (संभावित रूप से अद्यतन) रखा जाना चाहिए। दूसरे शब्दों में, आप संसाधन को बता रहे हैं "स्वयं को फिर से परिभाषित करने के लिए इस प्रस्तुति का उपयोग करें"।

PUT/संसाधन/foo/myvacation
सामग्री-प्रकार:: image/जेपीजी
...

और अनुवर्ती

इस प्रकार, मैं यह करने के लिए सक्षम होना चाहिए इस के साथ:

प्राप्त/संसाधन/foo/myvacation
स्वीकार करें: छवि/png
...

और अद्यतन किसी अन्य प्रारूप में myvacation के संस्करण प्राप्त (सर्वर यह सोचते हैं कि कैसे करना जानता है)। कि से Extrapolating, इस समग्र परमाणु "छवि + मेटाडेटा" PUT भी कानूनी होना चाहिए:

PUT/संसाधन/foo/myvacation
सामग्री-प्रकार: बहुखण्डीय/फार्म-डेटा

सामग्री-स्वभाव: फार्म डेटा; नाम = "दस्तावेज़"
सामग्री-प्रकार: छवि/जेपीजी
[..]
सामग्री-स्वभाव: फॉर्म-डेटा; नाम = "iptc"
सामग्री-प्रकार: एप्लिकेशन/आईपीटीसी
[..]
सामग्री-स्वभाव: फॉर्म-डेटा; नाम = "exif"
सामग्री-प्रकार: आवेदन/exif
[..]

और फिर, सर्वर साइड विषय बातचीत (RFC2616 खंड 12.1) कुछ भी बस के बारे में के आधार पर जगह ले सकते हैं, क्योंकि, हम

प्राप्त/संसाधन/foo/myvacation
सामग्री-प्रकार:: image/जेपीजी
[..]

इस के लिए "दस्तावेज़" सामग्री के लिए डिफ़ॉल्ट कर सकते हैं

या यदि आप मानते हैं कि मैं आरएफसी 2396 अनुभाग 3 करता हूं।4 "क्वेरी घटक संसाधन द्वारा व्याख्या की जाने वाली जानकारी की एक स्ट्रिंग है।" इसका मतलब है कि एक क्वेरी स्ट्रिंग वाला यूआरआई एक यूआरआई के रूप में एक क्वेरी स्ट्रिंग के बिना एक यूआरआई के रूप में संदर्भित करता है (और संसाधन के लिए केवल आवेदन/एक्स-फॉर्म-यूआरलेकोडेड डेटा भेजने के साथ आइसोमोर्फिक है), तो यह भी कानूनी होना चाहिए:

?

प्राप्त/संसाधन/foo/myvacation सामग्री = exif
सामग्री-प्रकार: आवेदन/exif
[..]

PUT का वर्णन कहते हैं:

PUT विधि अनुरोध कि संलग्न है डी इकाई आपूर्ति अनुरोध यूआरआई के तहत संग्रहीत किया जाना चाहिए।

मेरे लिए, यह काफी विरोधी है, जब तक कि आप इसे बहुत उदार तरीके से नहीं पढ़ते। मेरी व्याख्या है "पुट विधि अनुरोध करता है कि संलग्न इकाई के प्रतिनिधित्व के आधार पर आपूर्ति अनुरोध-यूआरआई पर संसाधन बनाया या अपडेट किया जाए।"

बाद में, हम पाते हैं:

पोस्ट के बीच मौलिक अंतर और अनुरोधों डाल अनुरोध- URI का अलग अर्थ में दिखाई देता है। एक POST अनुरोध में यूआरआई संसाधन की पहचान करता है जो संलग्न इकाई को संभालेगा। वह संसाधन डेटा-स्वीकार्य प्रक्रिया हो सकता है, किसी अन्य प्रोटोकॉल के लिए प्रवेश द्वार, या एक अलग इकाई जो एनोटेशन स्वीकार करती है। इसके विपरीत, एक पुट अनुरोध में यूआरआई अनुरोध के साथ संलग्न इकाई की पहचान करता है - उपयोगकर्ता एजेंट जानता है कि यूआरआई क्या इरादा रखता है और सर्वर को किसी अन्य संसाधन के अनुरोध को लागू करने का प्रयास नहीं करना चाहिए।

हमें इसी रचनात्मक रूप से इसे पढ़ने की आवश्यकता है, लेकिन यहां की मुख्य बिट्स "जानता है कि यूआरआई क्या इरादा है" और "अनुरोध लागू करें"।

तो, मेरे लिए किसी दिए गए यूआरआई में जीईटी द्वारा प्रस्तुत प्रतिनिधित्व को अनिवार्य रूप से वही प्रतिनिधित्व होना जरूरी नहीं है जो दिए गए यूआरआई को पॉट किया गया हो, यह सिर्फ सुसंगत होना चाहिए।

सच या गलत?

Answer 1

यदि आप बदल रहे हैं तो यह समझ में आएगा कि आप PUT क्या नहीं हैं GET, इसलिए मुझे नहीं लगता कि यह एक समस्या क्यों है।

लेकिन, यदि आप PUT कुछ जानकारी के साथ एक उपयोगकर्ता, फिर जब आप GET का उपयोग तो यह है कि व्यक्ति को पुनः प्राप्त करना चाहिए, बस के रूप में, जब मैं अपने 4 छुट्टी तस्वीर डाल दिया, जब मैं GET फोन मुझे लगता है कि तस्वीर की उम्मीद है, लेकिन यह हो सकता है एक अलग प्रारूप में परिवर्तित करके परिवर्तित किया जा सकता है, या कुछ अन्य परिवर्तन हो सकते हैं, लेकिन, अगर मुझे इसके बजाय 5 वां फोटो मिलता है, तो यह एक समस्या है।

Answer 2

इस तथ्य के आधार पर कि सामग्री बातचीत एक ही यूआरआई से अलग-अलग प्रतिनिधित्व लौटा सकती है, मुझे पूरा यकीन है कि आप जो भी प्राप्त करते हैं उसे उतना ही नहीं होना चाहिए जितना आप पुनर्प्राप्त करते हैं।

Answer 3

आपकी धारणाएं सही हैं। जीईटी को आपके द्वारा PUT के रूप में प्रतिनिधित्व को वापस करने की आवश्यकता नहीं है, लेकिन इसे संसाधन होना चाहिए।

मैं वर्तमान में एक वेब एप्लिकेशन पर काम कर रहा हूं जो सामग्री बातचीत वार्ता में पूछे जाने वाले कार्यों के आधार पर एक्सएचटीएमएल, जेएसओएन या कस्टम एक्सएमएल बोली के रूप में किसी भी संसाधन को वापस कर देगा। तो एक ब्राउज़र डिफ़ॉल्ट रूप से एचटीएमएल देखेंगे।XMLHttpRequest सहित अन्य HTTP क्लाइंट, JSON प्राप्त कर सकते हैं, और इसी तरह। वे एक ही यूआरआई में एक ही संसाधन के सभी प्रतिनिधित्व हैं।

इसी तरह, हमारे आवेदन

Answer 4

एक PUT या POST समर्थित किसी भी प्रारूप में स्वीकार करेंगे (प्रश्न में विशेष संसाधन या संग्रह के शब्दों के अधीन है।) मैं अन्य जवाब के साथ सहमत हैं कि संसाधन है कि आप डाल आपको बाद में प्राप्त करने की आवश्यकता नहीं है जिसे आप बाद में प्राप्त करते हैं। मैं इस क्षेत्र के आसपास इस प्रश्न में अपना कुछ अनुभव जोड़ना चाहता था।

सामग्री-बातचीत पर भरोसा करते समय आपको बहुत सावधान रहना होगा। सही होने के लिए यह बहुत मुश्किल है और यदि आपको यह सही नहीं लगता है तो यह खराब उपयोगकर्ता समस्याओं का कारण बनता है। आइए छवियों के आधार पर एक उदाहरण दें ...

यदि ऐलिस कच्चे प्रारूप में एक छवि डालता है, तो बॉब छवि को जेपीईजी (सर्वर पक्ष कच्चे-> जेपीईजी ट्रांसफॉर्म के माध्यम से) प्राप्त कर सकता है, और ऐलिस प्राप्त कर सकता है एक कच्चे प्रारूप में छवि; कोई समस्या नहीं। हालांकि, अगर बॉब एक ​​जेपीईजी डालता है, तो एलिस के कच्चे प्रारूप में वापस आने का कोई तरीका नहीं है। छुट्टी तस्वीरें के मामले में सममित परिवर्तनों की कमी एक बड़ा सौदा नहीं हो सकता है, लेकिन चिकित्सा छवियों में यह होगा।

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