REST इंटरफ़ेस के माध्यम से VM को बंद करना
यह वास्तव में एक प्रसिद्ध उदाहरण है, 2009 में टिम ब्रे द्वारा सामने रखा गया ।
रॉय फील्डिंग, समस्या पर चर्चा करते हुए, इस अवलोकन को साझा किया :
मैं व्यक्तिगत रूप से उन प्रणालियों को प्राथमिकता देता हूं जो निगरानी की स्थिति (जैसे बिजली की स्थिति) को गैर-संपादन योग्य मानते हैं।
संक्षेप में, आपके पास एक सूचना संसाधन है जो मॉनिटर किए गए राज्य का एक वर्तमान प्रतिनिधित्व लौटाता है; कि प्रतिनिधित्व एक करने के लिए एक हाइपरमीडिया लिंक शामिल हो सकता है प्रपत्र कि कि राज्य में परिवर्तन का अनुरोध करने के लिए, और प्रपत्र हैंडल (प्रत्येक) परिवर्तन अनुरोध करने के लिए एक संसाधन के लिए एक और कड़ी है।
सेठ लड्डू की समस्या में प्रमुख अंतर्दृष्टि थी
हमने एक व्यक्ति की एक सरल अवस्था से एक सच्चे संज्ञा की ओर भाग रहे हैं, जिसे बनाया जा सकता है, अद्यतन किया जा सकता है और इसके बारे में बात की जा सकती है।
इसे रीबूटिंग मशीनों पर वापस ले जाना। मेरा तर्क है कि आप पोस्ट / vdc / 434 / क्लस्टर / 4894 / सर्वर / 4343 / रिबूट करने के बाद एक बार पोस्ट करने के बाद आपके पास एक यूआरआई होगा जो इस रिबूट का प्रतिनिधित्व करता है , और आप इसे स्टेटस अपडेट के लिए प्राप्त कर सकते हैं। हाइपरलिंकिंग के जादू के माध्यम से, रिबूट का प्रतिनिधित्व रिबूट किए गए सर्वर से जुड़ा हुआ है।
मुझे लगता है कि मिंटिंग यूआरआई स्पेस सस्ता है, और यूआरआई भी सस्ता है। गतिविधियों का एक संग्रह बनाएँ, जो Nouns और POST, PUT, और DELETE के रूप में निर्मित हैं!
रैस्टफुल प्रोग्रामिंग वेब पैमाने पर वोगन नौकरशाही है। आप कुछ भी कैसे करते हैं ? इसके लिए नई कागजी कार्रवाई का आविष्कार करें, और कागजी कार्रवाई को डिजिटल करें।
कुछ हद तक कट्टर भाषा में, आप जो कर रहे हैं, वह "वीएम को बंद करने" के लिए डोमेन एप्लिकेशन प्रोटोकॉल को परिभाषित कर रहा है , और उस प्रोटोकॉल को उजागर करने / लागू करने के लिए आवश्यक संसाधनों की पहचान करना है।
अपने स्वयं के उदाहरणों को देखते हुए
PATCH /api/virtualmachines/42
Content-Type:application/json
{ "state": "shutting down" }
ठीक है; आप वास्तव में अनुरोध को अपने स्वयं के अलग सूचना संसाधन के रूप में नहीं मान रहे हैं, लेकिन आप अभी भी प्रबंधित कर सकते हैं।
आप परिवर्तन के अपने प्रतिनिधित्व में थोड़ा चूक गए हैं।
PATCH के साथ, हालांकि, संलग्न इकाई में निर्देशों का एक सेट होता है, जो बताता है कि वर्तमान में मूल सर्वर पर रहने वाले संसाधन को एक नया संस्करण बनाने के लिए कैसे संशोधित किया जाना चाहिए।
उदाहरण के लिए, JSON पैच मीडिया प्रकार के प्रारूप निर्देश जैसे कि आप सीधे JSON दस्तावेज़ को संशोधित कर रहे थे
[
{ "op": "replace", "path": "state", "value": "shutting down" }
]
आपके विकल्प में, विचार करीब है, लेकिन स्पष्ट रूप से सही नहीं है। लक्ष्य URL परPUT संसाधन की स्थिति का पूर्ण प्रतिस्थापन है , इसलिए आप संभवतः एक वर्तनी का चयन नहीं करेंगे जो किसी एकल इकाई के प्रतिनिधित्व के लक्ष्य के रूप में एक संग्रह की तरह दिखता है ।
POST /api/virtualmachines/42/actions
कथा के अनुरूप है कि हम एक कतार में एक कार्रवाई जोड़ रहे हैं
PUT /api/virtualmachines/42/latestAction
कथा के अनुरूप है कि हम कतार में पूंछ आइटम के लिए एक अद्यतन कर रहे हैं; यह इस तरह से करना थोड़ा अजीब है। कम से कम आश्चर्य का सिद्धांत प्रत्येक पीयूटी को देने की सिफारिश करता है, यह एक अद्वितीय पहचानकर्ता है, न कि उन सभी को एक ही स्थान पर रखना और एक ही समय में कई संसाधनों को संशोधित करना।
ध्यान दें, जहाँ तक हम URI की वर्तनी पर चर्चा कर रहे हैं - REST परवाह नहीं करता है; /cc719e3a-c772-48ee-b0e6-09b4e7abbf8bजहाँ तक REST का सवाल है, एक पूरी तरह से cromulent URI है। चर नामों के साथ पठनीयता एक अलग चिंता का विषय है। RFC 3986 के साथ संगत वर्तनी का उपयोग करना लोगों को बहुत खुश कर देगा।
CQRS
क्या होगा यदि हमारे पास कई ऐसे "कार्यों" (उर्फ कमांड) के साथ एक CQRS डोमेन है जो संभावित रूप से कई एग्रीगेट्स के अपडेट का कारण बन सकता है या कंक्रीट संसाधनों और उप-संसाधनों पर सीआरयूडी संचालन के लिए मैप नहीं किया जा सकता है?
CQRS पर ग्रेग यंग
CQRS एक बहुत ही सरल पैटर्न है जो वास्तुकला के कई अवसरों को सक्षम करता है जो अन्यथा मौजूद नहीं हो सकते हैं। CQRS अंततः सुसंगतता नहीं है, यह ईवेंट नहीं है, यह मैसेजिंग नहीं है, यह पढ़ने और लिखने के लिए अलग मॉडल नहीं है, और न ही यह इवेंट सोर्सिंग का उपयोग कर रहा है।
जब अधिकांश लोग CQRS के बारे में बात करते हैं तो वे वास्तव में CQRS पैटर्न को उस वस्तु पर लागू करने के बारे में बोल रहे हैं जो अनुप्रयोग की सेवा सीमा का प्रतिनिधित्व करता है।
यह देखते हुए कि आप HTTP / REST के संदर्भ में CQRS के बारे में बात कर रहे हैं, यह मानना उचित है कि आप इस बाद के संदर्भ में काम कर रहे हैं, तो चलिए उसी के साथ चलते हैं।
यह आश्चर्यजनक रूप से, आपके पिछले उदाहरण की तुलना में अधिक आसान है। इसका कारण सरल है: आदेश संदेश हैं ।
जिम वेबर HTTP को 1950 के दशक के कार्यालय के अनुप्रयोग प्रोटोकॉल के रूप में वर्णित करता है; संदेश लेकर और उन्हें इनबॉक्स में डालकर काम हो जाता है। एक ही विचार रखता है - हमें एक फॉर्म की एक खाली प्रति मिलती है, इसे उन बारीकियों के साथ भरें जिन्हें हम जानते हैं, इसे वितरित करें। ता दा
क्या हमें कंक्रीट के संसाधनों पर कंक्रीट बनाने या अपडेट के रूप में कई कमांडों को मॉडल करने की कोशिश करनी चाहिए, जहां कभी भी संभव हो (उदाहरण के लिए पहले दृष्टिकोण का अनुसरण करते हुए) और बाकी के लिए "एक्शन एंडपॉइंट्स" का उपयोग करें?
हां, डोमेन मॉडल में संस्थाओं के बजाय "ठोस संसाधन" के रूप में इंसोफर संदेश हैं।
मुख्य विचार: आपका REST API अभी भी एक इंटरफ़ेस है ; आपको संदेशों को बदलने की आवश्यकता वाले क्लाइंट के बिना अंतर्निहित मॉडल को बदलने में सक्षम होना चाहिए। जब आप एक नया मॉडल जारी करते हैं, तो आप अपने वेब एंडपॉइंट्स का एक नया संस्करण जारी करते हैं, जो आपके डोमेन प्रोटोकॉल को लेना और नए मॉडल पर लागू करना जानता है।
क्या CQRS मॉडल एक RPC जैसे API के लिए बेहतर फिट है?
वास्तव में नहीं - विशेष रूप से, वेब कैश एक "अंततः सुसंगत रीड मॉडल" का एक शानदार उदाहरण है। अपने प्रत्येक विचार को स्वतंत्र रूप से संबोधित करते हुए, प्रत्येक अपने स्वयं के कैशिंग नियमों के साथ, आपको मुफ्त में स्केलिंग का एक गुच्छा देता है। पढ़ने के लिए विशेष रूप से RPC दृष्टिकोण के लिए अपेक्षाकृत कम अपील है।
लिखने के लिए, यह एक पेचीदा प्रश्न है: सभी कमांड को एक सिंगल हैंडपॉइंट पर एक ही हैंडलर या एंडपॉइंट के एकल परिवार को भेजना, निश्चित रूप से आसान है । REST वास्तव में इस बारे में अधिक है कि आप यह कैसे पाते हैं कि क्लाइंट के लिए समापन बिंदु कहां है।
एक संदेश को अपने स्वयं के अनूठे संसाधन के रूप में मानने से यह फायदा होता है कि आप PUT का उपयोग कर सकते हैं, मध्यस्थ घटकों को इस तथ्य से सचेत कर सकते हैं कि संदेश को संभालना बेकार है, ताकि वे त्रुटि से निपटने के कुछ मामलों में भाग ले सकें, यह एक अच्छा है । (नोट: कि ग्राहकों के दृष्टिकोण से, यदि संसाधनों में अलग-अलग यूआरआई हैं, तो वे अलग-अलग संसाधन हैं। तथ्य यह है कि उनके पास मूल सर्वर पर एक ही अनुरोध हैंडलर कोड हो सकता है, जो वर्दी द्वारा छिपाए गए कार्यान्वयन विवरण है। इंटरफेस)।
क्षेत्ररक्षण (2008)
मुझे यह भी ध्यान देना चाहिए कि उपरोक्त अभी तक पूरी तरह से Restful नहीं है, कम से कम मैं कैसे शब्द का उपयोग करता हूं। मेरे द्वारा किए गए सभी सेवा इंटरफेस को वर्णित किया गया है, जो किसी भी आरपीसी से अधिक नहीं है। इसे RESTful बनाने के लिए, मुझे सेवा शुरू करने और परिभाषित करने के लिए हाइपरटेक्स्ट जोड़ने की आवश्यकता होगी, वर्णन करें कि फॉर्म और / या लिंक टेम्प्लेट का उपयोग करके मैपिंग कैसे करें, और विज़ुअलाइज़ेशन को उपयोगी तरीकों से संयोजित करने के लिए कोड प्रदान करें।