संसाधन

Question

के लिए स्थिति बदलने के लिए आराम uri डिज़ाइन मेरे पास एक संसाधन है जो यूआरआई /resources/{resource_identifier} पर पहुंच सकता है और इसमें 'स्थिति' संपत्ति है जिसे मैं सुलभ बनाना चाहता हूं। मैंने इसके लिए कुछ विकल्पों के बारे में सोचा है, जो 'सर्वश्रेष्ठ' या 'सबसे पुराना' होगा?

यूआरआई पर विकल्प एक संलग्न कार्यों और इन यूआरआई

/resources/{resource_identifier}/void  
/resources/{resource_identifier}/open  
/resources/{resource_identifier}/close 

यह हालांकि अनाड़ी लग रहा है के लिए ग्राहक POST है।

---

विकल्प दो उपयोग यूआरआई में क्वेरी परम और है ग्राहक इन

/resources/{resource_identifier}?transition=void 
/resources/{resource_identifier}?transition=open 
/resources/{resource_identifier}?transition=close 

---

विकल्प तीन उपयोग अनुरोध के पेलोड को PATCH और ग्राहक है PUT

/resources/{resource_identifier} 

पेलोड विकल्प:

{ ..., "status" :"void" } 
{ ..., "status" :"open" } 
{ ..., "status" :"close" } 

---

या हो सकता है पूरी तरह से कुछ और?

Answer 1

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

क्यों नहीं सिर्फ इस कार्य करें:

PUT/resources/:id के लिए और अनुरोध के साथ डेटा transition=void भेजें।

यह वैसे ही व्यवहार करता है यदि आप POST अनुरोध प्राप्त कर रहे थे, तो बस अनुरोध निकाय के डेटा को पकड़ लें।

Answer 2

संसाधन के रूप में 'स्थिति' क्यों नहीं है। आप इसे प्रबंधित कर सकते हैं। यह भी मान लें कि {resource_identifier} संसाधन निर्माण के हिस्से के रूप में पहले से ही 'स्थिति' बनाई जानी चाहिए और स्थिति के लिए पहले से ही एक डिफ़ॉल्ट मान है।

फिर व्यापार तर्क की आवश्यकता बाकी कॉल के माध्यम से स्थिति को 'अपडेट' करने के लिए है और इसलिए 'PUT' का उपयोग किया जाना चाहिए।

अद्यतन करने के लिए स्थिति आगे बढ़ते रखें शरीर

PUT: /resources/{resource_identifier}/status/ 

Body: {void | open | close } 

Answer 3

पहला विकल्प स्पष्ट रूप से आराम नहीं है; आपके पास यूआरआई में 'क्रियाएं' हैं और POST का उपयोग कर रहे हैं, जो एक नया संसाधन बनाना है, जिसे आप स्पष्ट रूप से करने का प्रयास नहीं कर रहे हैं।

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

यदि हम अब अनुरोध की विधि पर विचार करते हैं। मेरी पुस्तक में, यह अपेक्षाकृत सरल है, मुझे लगता है कि स्थिति इस संसाधन का केवल एक क्षेत्र है, और इसलिए यदि आप केवल आंशिक अद्यतन कर रहे हैं, तो आप संसाधन को पैच कर रहे हैं, और इस प्रकार PATCH उपयोग करने की विधि है। ऑफ मौके पर 'स्थिति' एकमात्र संपत्ति है, फिर स्थिति बदलना पूरी तरह से संसाधन बदल रहा है और इस प्रकार PUT स्वीकार्य होगा; लेकिन मुझे संदेह है कि वास्तव में मामला है।

जैसा कि यह खड़ा है, तीसरे विकल्प के यूआरआई, PATCH के उपयोग के साथ संयुक्त रूप से सबसे अच्छा विकल्प है।

PATCH /resources/{resource_identifier} 

{ "status" :"close" } 

बेशक

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

PUT /resources/{resource_identifier}/status 

close 

---

ध्यान रखें, वहाँ, बाकी करने का कोई "सही" तरीका है बस "बुरा नहीं" तरीके। यह एक शैली है, एक नियम सेट नहीं है।

मैं यह भी सुझाव देता हूं कि आप मानते हैं कि कई प्रारूपों को लेने में सक्षम होना एक वांछनीय विशेषता है, आमतौर पर बोलना। इस प्रकार, पहला विकल्प काम करना आसान हो जाता है। उदाहरण के तौर पर आप जेएसओएन ले सकते हैं, या एक्सएमएल <status>close</ status>, या एक साधारण कुंजी मूल्य जोड़ी status=closed आदि