REST URI में क्रियाओं (क्रियाओं) का प्रतिनिधित्व करते हैं

Question

मेरे पास अपने ग्राहक दस्तावेजों के लिए प्रदर्शन करने के लिए एक प्रिंट ऑपरेशन है। मुझे ऐड, अपडेट, डिलीट जैसे अन्य मानक संचालन की आवश्यकता है। इसलिए, मेरे पास निम्नलिखित हैं:

• नया ग्राहक बनाने के लिए:
  URI = / customer / {id}, प्रकार = POST, Methodname = CreateCustomer ()
• अपडेट करने के लिए:
  URI: / customer / {id}, टाइप करें = PUT, विधि = UpdateCstomer ()
• ग्राहक को हटाएं:
  URI = / customer / {id}, प्रकार = DELETE, Methodname = DeleteCustomer ()
• दृश्य के लिए:
  URI: / ग्राहक / {आईडी}, प्रकार = प्राप्त करें, विधि = GetCustomer ()

अब, अगर मुझे उस ग्राहक के लिए एक दस्तावेज़ प्रिंट करने की आवश्यकता है, तो मुझे एक प्रिंट फ़ंक्शन की आवश्यकता है। मेरा URI इस तरह दिख सकता है: / ग्राहक / {आईडी}, प्रकार = POST, विधि = PrintCustomer ()। लेकिन मैंने CreateCustomer के लिए उस URI और POST प्रकार का उपयोग किया है। मैं चाहता था कि यूआरआई इस तरह दिखे: / ग्राहक / प्रिंट / {आईडी}, टाइप = POST, विधि = PrintCustomer ()।

लेकिन मैं अपने URI में "प्रिंट" क्रिया नहीं कर सकता। ऐसा करने का सबसे अच्छा तरीका क्या है? मैंने URI के रूप में / ग्राहक / दस्तावेज़ / {id} के बारे में सोचा था ... लेकिन मैं उसी मुद्दे पर चलूंगा। मेरे पास "दस्तावेज़" पर CRUD संचालन होगा। इसलिए, फिर से मैं "प्रिंट" के लिए उपयोग किए जाने वाले उपकरण से बाहर निकलता हूं। कृपया सलाह दें।

Comments

मुद्रण आमतौर पर एक क्लाइंट-साइड ऑपरेशन है, इसलिए मैं उत्सुक हूं - आपका सेटअप ऐसा कैसे है कि आपको एक REST सर्वर पर कमांड भेजने की आवश्यकता है?

— शौना

@ शऊना जरूरी नहीं है, यूआरआई सर्वर के लिए एक प्रिंट-फ्रेंडली संस्करण के लिए एक अनुरोध हो सकता है (यानी एक अलग दृश्य)।

— इवान प्लाइस

@EvanPlaice - पर्याप्त रूप से, हालांकि, जो अभी भी क्लाइंट के लिए मुद्रण का कार्य छोड़ देता है (जो, सर्वर-साइड प्रिंट-फ्रेंडली संस्करण लाने के बाद भी, यह तय करेगा कि प्रिंट करने के लिए क्या डिवाइस प्रिंट करें और स्वयं भेजें, भले ही कमांड एक प्रिंट सर्वर को जाता है)। एक संसाधन के एक प्रिंट के अनुकूल संस्करण प्राप्त करने के लिए एक अनुरोध तो तार्किक होगा ... अच्छी तरह से ... GET।

— शौना

@ एक HTTP अनुरोध से प्रिंट कार्य को ट्रिगर करना ब्राउज़र सुरक्षा के कारण अकेले असंभव होगा। प्रिंट-फ्रेंडली संस्करण के लिए एक अनुरोध केवल एक GET अनुरोध है, लेकिन आपको अभी भी यह निर्दिष्ट करने की आवश्यकता है कि ब्राउज़र को मुद्रण योग्य संस्करण प्रस्तुत करना चाहिए। आप एक अलग URL निर्दिष्ट कर सकते हैं, लेकिन यह REST के सिद्धांतों का उल्लंघन करेगा क्योंकि आप वास्तव में एक अलग संसाधन का अनुरोध नहीं कर रहे हैं, बस एक ही संसाधन का एक अलग परिवर्तन। इसलिए क्वेरी-पैरामीटर और / या सामग्री-प्रकार के माध्यम से परिवर्तन को निर्दिष्ट करने का कारण।

— इवान प्लाइस

मेरे पास उत्तर के रूप में पोस्ट करने के लिए पर्याप्त प्रतिनिधि नहीं है, लेकिन मुझे यह दिलचस्प लगता है कि tyk.io/rest-never-crud का तर्क है कि POST /customers/123/printऐसा करना एक मान्य बात है।

— jlh

Answer 1

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

मुद्रण के मामले में, आपको मुद्रण के कार्य को एक संसाधन के रूप में समझना चाहिए। आप सिस्टम से आपके लिए "प्रिंट जॉब" बनाने के लिए कह रहे हैं। इसका मतलब है कि आपके पास एक prints/संसाधन हो सकता है जो अनुरोध किए गए सभी प्रिंट के लिए कंटेनर के रूप में कार्य करता है। जब आप किसी चीज़ POSTको इस संसाधन के लिए प्रिंट करना चाहते हैं जिसमें आपके द्वारा प्रिंट किए जाने वाले संसाधनों की पहचान करना चाहते हैं, तो उन संसाधनों की पहचान करना, जिन्हें आप उनके लिंक के साथ प्रिंट करना चाहते हैं।

JSON दस्तावेज़ के रूप में, यह इस तरह दिख सकता है:

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

जाहिर है, आपको यह अनुकूलित करने की आवश्यकता है कि आप क्या करना चाहते हैं, इसके लिए प्रासंगिक होना चाहिए। मुख्य बात यह है कि आप अपने URL को निर्दिष्ट करके प्रिंट करने के लिए अन्य संसाधनों की पहचान कर रहे हैं।

अनुरोध के जवाब में, आप बस एक 200 OKया एक वापसी कर सकते हैं 204 No-Contentऔर इसे आग और भूलने की प्रक्रिया के रूप में मान सकते हैं। हालाँकि, यदि आप इसे बढ़ाना चाहते हैं, तो आप वापस आ सकते हैं 201 Createdऔर नए बनाए गए प्रिंट जॉब के URL को निर्दिष्ट कर सकते हैं , जैसे /prints/12345।

एक उपयोगकर्ता तब GETअपनी प्रिंट नौकरी की स्थिति (लंबित, प्रगति, आदि) देखने के लिए संसाधन पर प्रदर्शन कर सकता है, या ए जारी करके नौकरी को रद्द करने का अनुरोध कर सकता है DELETE।

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

Comments

आमतौर पर POST का मतलब होता है क्रिएट / इंसर्ट, जबकि put का मतलब आमतौर पर अपडेट सेव / अपडेट होता है। यही कारण है कि यह REST में परिभाषित नहीं है, भले ही यह HTML में आमतौर पर इसका उपयोग कैसे न किया गया हो।

— इवान प्लाइस

@EvanPlaice HTTP कल्पना नाम बनाएँ / अद्यतन क्रिया के रूप में PUT करें (यह अधिक परिचित बनाने + पुनर्प्राप्त करने के लिए + अद्यतन मॉडल का उपयोग करता है) और POST "डेटा प्रोसेसिंग" क्रिया है, साथ ही साथ "परिशिष्ट" क्रिया है । रॉय फील्डिंग ने अपने ब्लॉग में POST का उपयोग उस क्रिया के रूप में किया है जब आप ऑपरेशन को मानकीकृत नहीं करना चाहते हैं। जब आप इसे आइटम के संग्रह में एक नया आइटम जोड़ने पर विचार करते हैं तो POST "सृजन" शब्दार्थ लेता है। इस मामले में, ट्रेजेडियन ने प्रसंस्करण के लिए POST का उपयोग करते हुए या एक प्रिंट नौकरी को जोड़ने के लिए सिर पर नाखून मारा।

— रोब

@ रॉबी ओके, यह समझ में आता है। एक उदाहरण के रूप में, PUT को एक डेटाबेस में डेटा दर्ज करने के लिए डिज़ाइन किए गए SPROC का प्रतिनिधित्व करने के लिए इस्तेमाल किया जा सकता है। जबकि, एक POST उस डेटा को इकट्ठा / तैयार करने के लिए आवश्यक मध्यवर्ती चरण और परिवर्तन कर सकता है। POST ऑपरेशन का डिज़ाइन बदल सकता है या बदल सकता है क्योंकि डिज़ाइन विकसित होता है लेकिन PUT संचालन उस मॉडल का प्रतिनिधित्व करता है जिसे (आदर्श रूप से) बदलना नहीं चाहिए। मैं अपना उत्तर अपडेट करूंगा लेकिन यह पहले से ही अंतर को समझाने का एक बड़ा काम करता है।

— इवान प्लाइस

Answer 2

मैंने पहले भी ऐसा किया है। एक दस्तावेज़ मुद्रित करने के लिए मैं सिर्फ एक संसाधन का एक पीडीएफ संस्करण लौटाता हूं। क्लाइंट को केवल स्वीकार्य हेडर एप्लिकेशन / पीडीएफ के साथ संसाधन के लिए एक GET अनुरोध भेजने की आवश्यकता है।

यह प्रिंट कार्य जैसे अस्थायी संसाधन के लिए नए URI बनाने से भी बचता है। HTTP हैडर का उपयोग भी REST का हिस्सा है और यह URI को साफ रखता है।

Answer 3

बस वर्तमान URI के GET में एक पैरामीटर जोड़ें

यह कई कार्यों के लिए एक यूआरआई का उपयोग करने के लिए बहुत विशिष्ट है।

यदि आप एक ही संसाधन लेकिन एक अलग कार्रवाई के बारे में बात कर रहे हैं, तो आप इसे एक पैरामीटर के रूप में परिभाषित करेंगे।

/ ग्राहक / {आईडी}? प्रिंट = true

फिर जहां आप अपनी GET विधि को परिभाषित करते हैं, आप प्रिंट पैरामीटर की उपस्थिति का पता लगाते हैं और इसे अलग तरीके से संभालते हैं।

REST को निम्नलिखित तरीके से परिभाषित किया गया है:

• POST - एक रिकॉर्ड, संपत्ति या संसाधन बनाएँ
• PUT - अपडेट, एक रिकॉर्ड, संपत्ति या संसाधन
• DELETE - एक, रिकॉर्ड, संपत्ति, या संसाधन निकालें

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

REST विनिर्देशन बहुत आगे की सोच है, भले ही एपीआई केवल हाल ही में इसका भारी उपयोग करना शुरू कर रहे हैं।

यदि आप REST प्रोटोकॉल के बारे में अधिक जानने में रुचि रखते हैं, तो मेरा सुझाव है कि आप " हैटर्स गोना हेट हेटोस " पढ़ें ।

---

अपडेट करें:

@ शहाना ने मेरे तर्क में एक दिलचस्प छेद बताया। कोई सही सही तरीका नहीं है और कई रूपों को स्वीकार्य माना जाता है। मैंने इसके बारे में कुछ और सोचा और चूंकि आपका इरादा डेटा को अलग प्रतिनिधित्व में बदलने का है, इसलिए यह परिवर्तन को नए MIME- प्रकार के रूप में परिभाषित करने के लिए समझ में आता है।

उदाहरण के लिए, आप URI का प्रतिनिधित्व कर सकते हैं:

/customer/{id}+print

जहाँ आप पाठ / html + प्रिंट के लिए प्रतिक्रिया सामग्री-प्रकार निर्धारित कर सकते हैं। इस तरह आपके पास भविष्य में अधिक परिवर्तनों को परिभाषित करने का विकल्प भी होगा।

उदाहरण के लिए:

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

किसी भी तरह से, सभी फॉर्म स्वीकार्य हैं। आपके द्वारा तय किया गया कार्यान्वयन व्यक्तिगत प्राथमिकता और आपके सर्वर की क्षमताओं पर अधिक निर्भर करता है।

एक तरफ: मुझे स्पष्ट करने के बाद से कुछ भ्रम होने लगता है। संसाधन कैसे परिवर्तित किया जाता है, यह निर्दिष्ट करने के लिए 'प्रिंट' क्वेरी-पैरामीटर और / या सामग्री-प्रकार का उपयोग किया जाता है। फिजिकल प्रिंट जॉब को ट्रिगर करने का तरीका नहीं। सुरक्षा कारणों से, हार्डवेयर-स्तर का उपयोग हमेशा उपयोगकर्ता / ग्राहक / ब्राउज़र के लिए छोड़ दिया जाता है।

Comments

जोड़ने के लिए - क्वेरी स्ट्रिंग ( ?print=true) का उपयोग करने के विकल्प के रूप में , आप यूआरआई मापदंडों (यानी - /customer/{id}/printable) का उपयोग कर सकते हैं । जो आप उपयोग करते हैं वह काफी हद तक आपके सिस्टम (सीएमएस, फ्रेमवर्क, कोड इन जनरल) पर निर्भर करेगा। दोनों को मान्य और स्वीकार्य माना जाता है ।

— शौना

@ शऊना तकनीकी रूप से, सबसे अच्छा तरीका URI '/ ग्राहक / {आईडी} + प्रिंट' और एक प्रतिक्रिया MIME- प्रकार का टेक्स्ट / html + प्रिंट के साथ मुद्रण के लिए एक MIME- प्रकार के लिए नियोजित होगा। इस तरह के एक दृष्टिकोण का लाभ, आप एक ही URI के लिए कई MIME-type (ex text / html, text / x-markdown, application / json, आदि) के लिए ट्रांसफ़ॉर्म बना सकते हैं। आपके द्वारा प्रस्तुत समाधान का नुकसान, आपको हर अलग MIME-Type के लिए एक अतिरिक्त URI (और किसी अन्य मार्ग को परिभाषित करना) बनाने की आवश्यकता होगी। यह थोड़े REST के उपयोग के उद्देश्य को पराजित करता है।

— इवान प्लाइस

(cont) मेरा तर्क है कि URI-hack मुख्य रूप से ROR समुदाय द्वारा शुरू किए गए एक विरोधी पैटर्न हैं लेकिन इसका मतलब यह नहीं है कि वे उपयोगी नहीं हैं। बेहतर निम्न-स्तरीय HTTPd सर्वरों के आने से REST को इस तरह से लागू करना आसान हो गया है जो पूरी तरह से इसकी क्षमता का लाभ उठाता है। चीजें उन दिनों से बहुत आगे आ गई हैं जहां Apache और index.html के माध्यम से सब कुछ रूट करना एकमात्र विकल्प था।

— इवान प्लाइस

GET को राज्य परिवर्तन नहीं करना चाहिए या इसके दुष्प्रभाव नहीं होने चाहिए। विचार करें कि जीईटी एक प्रकार का वृक्ष है, जिसका अर्थ है कि मिडलवेयर अनुरोध को पुनः प्राप्त कर सकता है यदि उसने इसे नहीं देखा है। इस मामले में, प्रत्येक पुन: प्रयास से दस्तावेज़ की एक नई, ताज़ा मुद्रित प्रति प्राप्त होगी। ;)

— रोब

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

— इवान प्लाइस