क्या यह एक ही पोस्ट में जटिल वस्तुओं को बनाने के लिए सही है?

Question

मेरे पास एक ऐसा फॉर्म है जहां उपयोगकर्ता व्यक्ति रिकॉर्ड बनाते हैं। प्रत्येक व्यक्ति कई गुण हो सकते हैं - ऊँचाई, वजन, आदि लेकिन वे भी इस तरह के हितों, पसंदीदा फिल्में, आदि

मैं कहाँ यह सब डेटा इकट्ठा किया जाता है एक ही रूप है के रूप में संबद्ध डेटा की सूची हो सकता है। मेरे लिए ऐसा लगता है कि मुझे इस डेटा के एक ही अनुरोध में पोस्ट करना चाहिए। लेकिन क्या वह सही है? मेरी पढ़ाई से पता चलता है कि रुचियों, पसंदीदा फिल्मों और अन्य सूचियों को अलग-अलग POST अनुरोधों में जोड़ा जाना चाहिए। लेकिन मुझे नहीं लगता कि यह समझ में आता है क्योंकि उनमें से एक असफल हो सकता है और फिर व्यक्ति का आंशिक सम्मिलन होगा और इसमें उनकी रुचियां या पसंदीदा फिल्में गायब हो सकती हैं।

Answer 1

मुझे नहीं लगता कि जब तक अपनी स्वाभाविक मुख्य संसाधन के साथ जुड़े एक अनुरोध में सभी डेटा जोड़ते समय समस्या है (अर्थात अपने मामले में व्यक्ति)। अगर ब्याज, एफएवी। फिल्में इत्यादि स्वयं के संसाधन हैं, उन्हें भी इस तरह संभाला जाना चाहिए।

Answer 2

मैं कहूंगा कि यह पूरी तरह से निर्भर डेटा की समायोज्यता और विशिष्टता पर निर्भर करता है।

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

इस के पीछे तर्क जब मूल पोस्ट के साथ बंडल कि संदर्भ है transactionality तात्पर्य; यानी, यदि कोई अन्य उपयोगकर्ता "पसंदीदा" फिल्म के लिए फिल्म संदर्भ को हटा देता है, जब इसे क्लाइंट पर चुना जाता है और जब POST जाता है, तो उपयोगकर्ता जोड़ देगा (उस डिज़ाइन द्वारा) असफल हो सकता है, जबकि अगर "पसंदीदा" फिल्म सहयोगी नहीं है लेकिन केवल एक विशेषता है, इसमें विफल होने के लिए कुछ भी नहीं है (गुण (संभवतः) किसी तृतीय पक्ष द्वारा अमान्य नहीं किया जा सकता है)।

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

Answer 3

बाकी हिस्सों में वास्तविक प्रतिबंध यह है कि एक परिवर्तनीय संसाधन है कि आप प्राप्त करने के लिए, आप भी बिलकुल पलट गया और एक ही प्रतिनिधित्व वापस रख अपने राज्य को बदलने के लिए कर सकते हैं। या पोस्ट करें। चूंकि यह अन्य चीजों के बड़े बंडलों के संसाधनों को प्राप्त करने के लिए उचित (और बहुत आम) है, इसलिए चीजों के बड़े बंडलों को भी पूरी तरह से उचित है।

आरईएसटी में संसाधनों के बारे में बहुत व्यापक रूप से सोचें। वे डेटाबेस पंक्तियों के साथ एक-दूसरे को मैप कर सकते हैं, लेकिन उन्हें ऐसा करने की ज़रूरत नहीं है। एक एड्रेसेबल संसाधन अन्य एड्रेसेबल संसाधनों को एम्बेड कर सकता है, या उनमें लिंक शामिल कर सकता है। जब तक आप अंतर्निहित प्रोटोकॉल के संचालन (यानी HTTP प्राप्त पोस्ट पुट इत्यादि) के अपने प्रतिनिधित्व और अर्थशास्त्र का सम्मान कर रहे हैं, आरईएसटी के पास अन्य डिज़ाइन विचारों के बारे में कुछ भी कहना नहीं है जो आपके जीवन को आसान या कठिन बना सकते हैं।