REST API में सॉफ्ट डिलीट

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

मैंने हाल ही में हमारी एक REST सेवाओं में नरम विलोपन लागू किया है। जिन लोगों ने मुझे क्या किया, मैं आपको बिल्ली के लिए आमंत्रित करता हूं।

आवश्यक प्रविष्टि

हल्के हटाने का उपयोग करने के बारे में बहस बहुत पुरानी है। बस यहां और यहां के लंबे होलीवरों को देखें।

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

हमने फैसला किया कि दस्तावेज़ भंडारण के लिए हमारी सेवा में, नरम विलोपन आवश्यक है।

उत्साहपूर्ण दृष्टिकोण

यदि हम किसी सेवा में नरम विलोपन को लागू करना चाहते हैं, तो हमें यह समझने की आवश्यकता है कि इंटरफ़ेस के दृष्टिकोण से इसे कैसे देखना चाहिए। इंटरनेट पर एक खोज से पता चला कि लोगों के पास एक विशिष्ट प्रश्न यह है कि क्या पहले की तरह DELETE {संसाधन} का उपयोग करना है, या क्या PATCH पद्धति का उपयोग करना बेहतर है एक शरीर के साथ जिसमें {स्टेटस: 'डिलीट'} जैसे कुछ शामिल हैं ।

यहां लोगों की राय असमान है: पहले की तरह DELETE का उपयोग करना आवश्यक है। क्लाइंट के दृष्टिकोण से, अफ्रीका में विलोपन भी एक विलोपन है। कुछ भी नहीं बदलना चाहिए: यदि कोई संसाधन हटा दिया जाता है, तो यह दुर्गम हो जाता है; यदि ग्राहक संसाधन को हटाना चाहता है, तो वह जानता है कि HTTP DELETE विधि इस उद्देश्य के लिए है। यह इस बात के विवरण में ग्राहक को समर्पित करने के लिए आवश्यक नहीं है कि सेवा कैसे विलोपन को लागू करती है।

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

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

डिज़ाइन

हमारी REST सेवा ASP.NET वेब API पर Entity Framework का उपयोग करके बनाई गई है। जैसा कि मैंने कहा, मैं दस्तावेज़ नामक संसाधन के लिए एक नरम विलोपन करता हूं।

तो, पहले आपको कॉलम को संबंधित तालिका में जोड़ना होगा। झंडे के रूप में, मैं हटाए गए टाइमस्टैम्प का उपयोग करता हूं। यदि मान NULL नहीं है, तो संसाधन को हटा दिया गया माना जाता है। इसके अलावा, संसाधन को हटाने के बारे में जानकारी होना उपयोगी है।

ALTER TABLE Documents ADD Deleted datetime NULL, DeletedBy int NULL GO 

नियंत्रक में DELETE कार्रवाई अब केवल भौतिक रूप से रिकॉर्ड हटाने के बजाय इन क्षेत्रों के मूल्यों को निर्धारित करेगी। इसके अलावा, DELETE संग्रहित दस्तावेज़ के मानक संदर्भ के साथ एक निकाय लौटाएगा:

 { "links": { "archive": "documents/{id}/deleted" } } 

वास्तव में, यह एक महत्वपूर्ण बिंदु है: लिंक क्लाइंट को यह समझने में मदद करता है कि दस्तावेज़ हटाया नहीं गया है, लेकिन स्थानांतरित किया गया है ।

संग्रहीत दस्तावेजों के लिए नया नियंत्रक निम्नलिखित तरीके प्रदान करना चाहिए:

दस्तावेज़ प्राप्त / हटाए गए	हटाए गए सभी दस्तावेजों का एक संग्रह हो जाता है
दस्तावेज / {आईडी} / हटाए गए	हटाए गए दस्तावेज़ लौटाता है
POST दस्तावेज़ / {आईडी} / हटाए गए	हटाए गए दस्तावेज़ को पुनर्प्राप्त करता है; शरीर की आवश्यकता नहीं है; 201 रिटर्न बनाया
DELETE दस्तावेज़ / {आईडी} / हटाए गए	किसी दस्तावेज़ को भौतिक रूप से हटा देता है

कार्यान्वयन

प्रारंभ में, मैंने अपने डेटाबेस में दो विचार जोड़ने की योजना बनाई:

 CREATE VIEW DeletedDocuments AS SELECT * FROM Documents WHERE Deleted IS NOT NULL GO CREATE VIEW AvailableDocuments AS SELECT * FROM Documents WHERE Deleted IS NULL GO 

मुझे लग रहा था कि यह कम परेशानी होगी: कोड में शर्तों को स्थापित करने के बजाय, मुझे अपने DB संदर्भ में दो अलग-अलग DbSet गुण मिलते हैं। सच है, आपके पास मॉडल में दो समान इकाइयां हैं, लेकिन ईएफ के संदर्भ में इस तरह की पीओसीओ वस्तुओं की संपत्ति है - प्रत्येक तालिका बिल्कुल एक इकाई से मेल खाती है।

वैसे, एसक्यूएल में प्रतिनिधित्व अन्य मामलों में एंटिटी फ्रेमवर्क के लिए उपयोगी हो सकता है: उनकी मदद से, उदाहरण के लिए, यदि आप कई डीबी संदर्भ नहीं बनाना चाहते हैं, तो आप किसी अन्य डेटाबेस से तालिकाओं को संदर्भित कर सकते हैं।

हालांकि, मेरे मामले में, विचारों के साथ संख्या पास नहीं हुई। प्राधिकरण के दौरान, आपको सभी दस्तावेजों के साथ काम करने की आवश्यकता है, क्योंकि उपयोगकर्ताओं के पास मौजूदा दस्तावेज़ों के समान हटाए गए दस्तावेज़ों के समान अधिकार हैं।

इसलिए, मैंने DbContext में केवल एक DbSet दस्तावेज़ रखने का फैसला किया, और कोड में हर बार मुझे पता चलता है कि इस समय क्या आवश्यक है:

 var availableDocuments = DbContext.Documents.Where(d => d.Deleted == null); var deletedDocuments = DbContext.Documents.Where(d => d.Deleted != null); var allDocuments = DbContext.Documents; 

संबंधित संसाधन

एक दस्तावेज़ एक संसाधन है जो अन्य संसाधनों के साथ जुड़ा हुआ है। उदाहरण के लिए, हमारे पास एक दस्तावेज उर्फ ​​है। यही है, आप न केवल दस्तावेजों / {आईडी} पथ से एक दस्तावेज प्राप्त कर सकते हैं, बल्कि दस्तावेजों / {उपनाम} पथ से भी प्राप्त कर सकते हैं, जहां उपनाम एक अद्वितीय स्ट्रिंग है।

किसी दस्तावेज़ को हटाने के बाद, उससे जुड़े सभी उपनाम "अदृश्य" हो जाने चाहिए: यदि पहले ग्राहक को GET दस्तावेज़ों / उपनामों का उपयोग करके सभी उपनामों की एक सूची प्राप्त हुई थी, तो दस्तावेज़ को हटाने के बाद, सूची से उसके उपनाम गायब हो जाएंगे।

लेकिन वे डेटाबेस में बने रहे! हम उस स्थिति में दस्तावेज़ को पुनर्स्थापित करने की क्षमता प्रदान करना चाहते हैं जिसमें इसे हटा दिया गया था। इससे ग्राहक के लिए भ्रम पैदा हो सकता है: वह किसी अन्य दस्तावेज़ के लिए एक नया उपनाम जोड़ने का प्रयास कर रहा है, GET दस्तावेज़ों / उपनामों से लौटी सूची में ऐसी कोई पंक्ति नहीं है, और सेवा फिर भी इसे जोड़ने से इंकार करती है।

मुझे नहीं लगता कि यह एक गंभीर समस्या है। फिर भी, यदि आपको इसे हल करने की आवश्यकता है, तो आप समापन बिंदु GET दस्तावेज़ / हटाए गए / उपनाम जोड़ सकते हैं। तब सब कुछ जगह में गिर जाता है: सेवा एक उपनाम नहीं जोड़ सकती है, क्योंकि इस तरह का मूल्य पहले से ही दूरस्थ दस्तावेज़ द्वारा उपयोग किया जाता है।

सवाल उठ सकता है: क्या यह दस्तावेजों / उपनामों से लौटी सूची से एक उपनाम फेंकने के लायक है? उन्हें रहने दो! मुझे नहीं लगता कि इस तरह का फैसला सही होगा। फिर यह पता चलता है कि उपनामों की सूची में टूटे हुए लिंक होंगे, क्योंकि ग्राहक 404 नहीं लौटाएगा यदि ग्राहक उर्फ ​​द्वारा हटाए गए दस्तावेज़ को प्राप्त करने की कोशिश करता है। यदि यह दस्तावेज़ से जुड़े बाल संसाधनों की बात आती है, तो व्यवहार बिल्कुल वैसा ही होना चाहिए जैसे कि हम दस्तावेज़ को भौतिक रूप से हटा रहे थे।

पुरालेख की सफाई

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

लेकिन एक महत्वपूर्ण कमी है। आधार बढ़ने लगा है।

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

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