संसाधन को क्लोन करने के लिए REST API डिज़ाइन

Question

मैं संसाधन को क्लोन करने के लिए एक विश्वसनीय API विधि को डिज़ाइन करने के लिए swagger का उपयोग करके एक YAML दस्तावेज़ लिख रहा हूं। मेरे पास कुछ विकल्प हैं और यह नहीं पता कि कौन सा सबसे अच्छा होगा। कृपया कोई सलाह दे सकता है?

विकल्प:

1. उपभोक्ता लिए संसाधन वस्तु क्लोनिंग की जिम्मेदारी को त्यागने (जहां उपभोक्ता एक नई वस्तु पर गुण के लिए मान प्रदान करती है और फिर एक नई वस्तु बनाता है), इस प्रक्रिया को करने की आवश्यकता होगी एपीआई को दो अनुरोध शामिल हैं: स्रोत ऑब्जेक्ट के लिए संसाधन के विरुद्ध प्राप्त करें और फिर नया संसाधन बनाने के लिए उस संसाधन पर एक पोस्ट करें। ऐसा लगता है कि उपभोक्ता की ज़िम्मेदारी बहुत अधिक है।
2. वेबएडीवी HTTP एक्सटेंशन का उपयोग करना जो एक COPY विधि (see here) प्रदान करता है। ऐसा लगता है कि यह वही है जो मैं क्लोनिंग के लिए करना चाहता हूं। हालांकि, मैं/{संसाधन} के लिए संभव
3. पोस्टिंग जितना मानक तरीकों से चिपके चाहते हैं? ResourceIdToClone = {id} जहां resourceIdToClone एक वैकल्पिक पैरामीटर है। यह एक एपीआई पथ के साथ संघर्ष करेगा जो मेरे पास संसाधन बनाने के लिए पहले से है, जहां मैं पोस्ट बॉडी में एक स्कीमा जोड़ता हूं। इसका मतलब बनाने और क्लोनिंग के लिए/{resource}/POST का उपयोग करना होगा, और यह एसआरपी का उल्लंघन करेगा।
4. 'क्लोनेबल रिसोर्स' नामक एक नया संसाधन जोड़ना और/क्लोनेबल रिसोर्स/{resource_type}/{resource_source_id} पर एक पोस्ट करना। एक भेड़ को क्लोन करने के उदाहरण के लिए, आप एक पोस्ट/क्लोनेबल रिसोर्स/भेड़/10 पर पोस्ट करेंगे। इस तरह, मानक HTTP विधियों का उपयोग करना संभव होगा, किसी भी अन्य संसाधन पथ (या एसआरपी उल्लंघन) के साथ कोई संघर्ष नहीं होगा। हालांकि, मैं डोमेन में एक नया और संभावित रूप से अनावश्यक प्रकार जोड़ रहा हूं। मैं एक परिदृश्य के बारे में भी नहीं सोच सकता जब कोई उपभोक्ता इस संसाधन के लिए पोस्ट के अलावा कुछ भी करना चाहेगा, इसलिए मुझे कोड कोड की तरह लगता है।
5. /संसाधन/{आईडी} के खिलाफ एक प्राप्त करें = विधि = क्लोन। यहां लाभों में से एक यह है कि कोई अतिरिक्त संसाधन आवश्यक नहीं है और इसे एक साधारण वैकल्पिक क्वेरीस्ट्रिंग पैरामीटर द्वारा निर्धारित किया जा सकता है। मुझे पता है कि यहां जोखिमों में से एक यह है कि अगर कोई वेब पेज में यूआरएल है तो इसे एक जीईटी विधि का उपयोग करके पदों को हटाने या हटाने की खतरनाक हो सकती है क्योंकि इसे एक खोज इंजन द्वारा क्रॉल किया जा सकता है।

किसी भी मदद के लिए धन्यवाद!

Answer 1

परियोजना आवश्यकताओं और मेरी टीम के सदस्यों के बीच वरीयताओं की सीमा से प्रभावित, विकल्प 1 इस चरण में हमें सर्वश्रेष्ठ सेवा प्रदान करेगा।

• मानक HTTP तरीकों के अनुरूप सरल और स्पष्ट करेगी मेरी एपीआई
• वहाँ एक संसाधन क्लोनिंग के लिए एक एकल, सुसंगत दृष्टिकोण होगा। यह उपभोक्ता को क्लोनिंग कार्य को नामित करने के साथ मेरे पास इस मुद्दे से अधिक है।

Answer 2

यदि आप संसाधन को कॉपी करना चाहते हैं, तो हाँ, कॉपी एक स्पष्ट विकल्प है।

(और हां, सीपीवाई की परिभाषाओं को खींचना और आरडीएफ 4918 से बाहर निकलना अच्छा होगा ताकि वे वेबडीवी से उन्हें उलझा सकें)।

Answer 3

इनमें से अधिकतर विकल्प पूरी तरह से अच्छे विकल्प हैं। अंत में बस इसकी शैली पसंद है। यहां आपके प्रत्येक विकल्प पर मेरी टिप्पणियां दी गई हैं।

1. उपभोक्ता
   सामान्य तौर पर करने के लिए संसाधन वस्तु क्लोनिंग मैं वास्तव में इस समाधान के साथ एक समस्या नहीं है की जिम्मेदारी को त्यागने। उपयोगकर्ता को समझने और कार्यान्वित करने के लिए यह विकल्प बहुत सीधे आगे है। कुछ स्वामित्व क्लोनिंग कार्यक्षमता के साथ आने से बेहतर हो सकता है कि आपके उपयोगकर्ताओं को सीखना है कि कैसे उपयोग करना है।

2. WebDAV HTTP एक्सटेंशन एक कॉपी विधि
   मैं भी मानक तरीकों से चिपके चाहते प्रदान करता है जो का उपयोग करना। मैं COPY का उपयोग नहीं करता, लेकिन अगर आपने किया तो मैं डर नहींूंगा।

3. पोस्टिंग/{संसाधन}? ResourceIdToClone = {id}
   लिए यह एक पूरी तरह से अच्छा समाधान है। एक आरईएसटी दृष्टिकोण से, आप वास्तव में अपने बाकी एपीआई के साथ संघर्ष नहीं करते हैं। एक क्वेरी पैरामीटर वाला यूआरआई क्वेरी पैरामीटर के बिना यूआरआई की तुलना में एक अलग संसाधन की पहचान करता है। प्रश्न पैरामीटर संसाधनों की पहचान के लिए एक यूआरआई सुविधा है जिसे आप श्रेणीबद्ध रूप से संदर्भित नहीं कर सकते हैं। हालांकि, इन्हें अपने कोड में अलग करना मुश्किल हो सकता है क्योंकि अधिकांश आरईएसटी फ्रेमवर्क काम करते हैं। आप /{resource}/clone जैसे पदानुक्रमित यूआरआई को छोड़कर ऐसा कुछ कर सकते हैं। आप इस यूआरआई में पोस्ट कर सकते हैं और शरीर में resource_source_id पास कर सकते हैं।

4. 'CloneableResource' नामक एक नई संसाधन जोड़ना और/{resource_source_id}/CloneableResource/{resource_type} कर दिया पोस्ट प्रदर्शन
   एक बाकी के दृष्टिकोण से इस दृष्टिकोण के साथ कुछ भी गलत नहीं है, लेकिन मैं एक नया जोड़ने लगता है प्रकार अनावश्यक और एपीआई दोनों अव्यवस्थित है। हालांकि, मैं आपके अंतर्ज्ञान से असहमत हूं, ऐसे संसाधन होने में समस्या हो सकती है जिसमें केवल एक पोस्ट ऑपरेशन हो। हो जाता है। असली दुनिया में, सब कुछ अच्छी तरह से फिट, PUT, या हटा में फिट बैठता है।

5. /संसाधन/{आईडी}? विधि = क्लोन
   यह 5 कि मैं नज़रअंदाज़ नहीं कर सकते हैं की ही एकमात्र विकल्प है के खिलाफ एक मिलता है। यह आपके वर्णन से लगता है कि आप पहले ही समझ चुके हैं कि यह एक बुरा विचार क्यों है, इसलिए मुझे यकीन नहीं है कि आप इसे क्यों मान रहे हैं। हालांकि, आपको इसे एक अच्छा समाधान बनाने के लिए करना है, जीईटी को पोस्ट में बदलना है। यह तब # 3 समाधान के समान ही हो जाता है। एक क्वेरी पैरामीटर का उपयोग करने के बजाय यूआरआई पदानुक्रमित भी हो सकता है। POST /resource/{id}/clone भी काम करेगा।

मुझे आशा है कि यह सहायक होगा। आपके निर्णय के लिए गुड लक।