मुझे लगता है कि आपके पास यहां बेमेल को लागू करने के लिए एक उपयोगकर्ता-प्रक्रिया हो सकती है।
पहला: क्या कोई उपयोगकर्ता ईमानदारी से एक साथ एक फाइल में कई बदलाव करना चाहेगा ? एक नाम बदलना (जिसमें पथ का परिवर्तन शामिल हो सकता है या नहीं?), स्वामित्व का परिवर्तन, और शायद फ़ाइल सामग्री का परिवर्तन (तर्क के लिए) अलग-अलग कार्यों की तरह लगता है।
मामले को ले लो जहां जवाब "हाँ" है - आपके उपयोगकर्ता वास्तव में इन परिवर्तनों को एक साथ करना चाहते हैं।
उस मामले में, मैं दृढ़ता से किसी भी क्रियान्वयन कई घटनाओं भेजता है के खिलाफ की सलाह देते हैं - RenameFileCommand, MoveFileCommand, ChangeOwnerCommand- यह प्रतिनिधित्व करने के लिए एक उपयोगकर्ता के इरादे।
क्यों? क्योंकि घटनाएं विफल हो सकती हैं। शायद इसकी अत्यंत दुर्लभ, लेकिन आपके उपयोगकर्ता ने एक ऐसा ऑपरेशन प्रस्तुत किया जो परमाणु दिखे - यदि डाउनस्ट्रीम घटनाओं में से एक भी विफल हो जाता है, तो आपका एप्लिकेशन स्टेट अब अमान्य है।
आप एक संसाधन पर दौड़ के खतरों को भी आमंत्रित कर रहे हैं जो कि प्रत्येक घटना संचालकों के बीच स्पष्ट रूप से साझा किया गया है। आपको "ChangeOwnerCommand" इस तरह से लिखना होगा कि फ़ाइल का नाम और फ़ाइल पथ कोई फर्क नहीं पड़ता, क्योंकि वे उस समय तक तारीख से बाहर हो सकते हैं जब तक कमांड प्राप्त होती है।
फ़ाइलों को स्थानांतरित करने और नाम बदलने के साथ एक गैर-इवेंट संचालित रेस्टफुल सिस्टम को लागू करते समय, मैं ईटैग सिस्टम जैसी किसी चीज का उपयोग करके निरंतरता सुनिश्चित करना पसंद करता हूं - सुनिश्चित करें कि संपादित किए जा रहे संसाधन का संस्करण वह संस्करण है जिसे उपयोगकर्ता ने अंतिम बार पुनर्प्राप्त किया था, और यदि यह विफल रहा तब से संशोधित किया गया है। लेकिन यदि आप इस एकल उपयोगकर्ता ऑपरेशन के लिए कई कमांड भेज रहे हैं, तो आपको प्रत्येक कमांड के बाद अपने संसाधन संस्करण को बढ़ाना होगा - इसलिए आपके पास यह जानने का कोई तरीका नहीं है कि उपयोगकर्ता वास्तव में जिस संस्करण को पढ़ रहा है, वह उसी संस्करण में है। ।
मेरे कहने का मतलब यह है कि - क्या होगा यदि कोई व्यक्ति लगभग उसी समय फ़ाइल पर एक और ऑपरेशन करता है। 6 आदेश किसी भी क्रम में ढेर हो सकते हैं। यदि हमारे पास सिर्फ 2 परमाणु कमांड होते हैं, तो पहले वाली कमांड सफल हो सकती है और बाद की कमांड विफल हो सकती है "संसाधन को संशोधित किया गया है क्योंकि इसे अंतिम रूप से प्राप्त किया गया था"। लेकिन जब कमांड परमाणु नहीं होते हैं तो इसके खिलाफ कोई सुरक्षा नहीं है, इसलिए सिस्टम संगतता का उल्लंघन किया जाता है।
दिलचस्प बात यह है कि थॉटवर्क्स प्रौद्योगिकी रडार, जनवरी 2015 में अनुशंसित "रेस्ट विदाउट पीयूटी" नामक इवेंट आधारित आर्किटेक्चर जैसी किसी चीज़ के लिए एक आंदोलन है । यहाँ बिना PUT के आराम करने के बारे में काफी लंबा ब्लॉग है ।
अनिवार्य रूप से, विचार यह है कि POST, PUT, DELETE और GET छोटे अनुप्रयोगों के लिए ठीक हैं, लेकिन जब आपको यह सोचना शुरू करना होगा कि कैसे डाल और पोस्ट करें और हटाएं तो दूसरे छोर पर व्याख्या की जा सकती है, आप युग्मन का परिचय देते हैं। (उदाहरण के लिए "जब मैं अपने बैंक खाते से जुड़े संसाधन को हटाता हूं, तो खाता बंद कर दिया जाना चाहिए") और प्रस्तावित प्रस्ताव को रीस्ट को अधिक घटना वाले तरीके से व्यवहार करना है। यानी एक ही घटना संसाधन के रूप में उपयोगकर्ता के इरादे को पूरा करता है।
अन्य मामला सरल है। यदि आपके उपयोगकर्ता उन सभी कार्यों को एक साथ नहीं करना चाहते हैं, तो उन्हें न करें। प्रत्येक उपयोगकर्ता के इरादे के लिए एक घटना POST। अब आप अपने संसाधनों पर etag संस्करण का उपयोग कर सकते हैं।
अन्य अनुप्रयोगों के लिए जो आपके संसाधनों के लिए एक बहुत ही अलग एपीआई का उपयोग कर रहे हैं। जो परेशानी की तरह बदबू आ रही है। क्या आप अपने RESTful API के शीर्ष पर पुराने API का एक मुखौटा बना सकते हैं और उन्हें मुखौटा पर इंगित कर सकते हैं? यानी ऐसी सेवा को उजागर करें जो REST सर्वर के माध्यम से अनुक्रम में एक फ़ाइल में कई अपडेट करती है?
यदि आप पुराने समाधान के शीर्ष पर न तो RESTful इंटरफ़ेस का निर्माण करते हैं, और न ही REST समाधान के शीर्ष पर पुराने इंटरफ़ेस का एक पहलू बनाते हैं, और साझा डेटा संसाधन पर इंगित दोनों API को बनाए रखने का प्रयास करते हैं, तो आपको प्रमुख सिरदर्द का अनुभव होगा।