डेमेटर बनाम आरईएसटी

Question

डेमेटर का कानून (वास्तव में डेमेटर का सुझाव होना चाहिए) कहता है कि आपको अपने बच्चे की वस्तुओं को प्राप्त करने के लिए किसी वस्तु को "पहुंचने" नहीं देना चाहिए। यदि आप, ग्राहक के रूप में, कुछ गैर-तुच्छ संचालन करने की आवश्यकता है, तो अधिकांश समय डोमेन मॉडल जिसके साथ आप काम कर रहे हैं, उस ऑपरेशन का समर्थन करना चाहिए।

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

तो, आप आरईएसटी और डेमेटर को कैसे संतुलित करते हैं? ऐसा लगता है कि वे संघर्ष में नहीं हैं, क्योंकि आरईएसटी उस बिंदु पर सुपर-ढीले युग्मन के बारे में है जहां प्रदाता के लिए ग्राहकों की सभी ज़रूरतों को पूरा करने की कोशिश करने के लिए यह व्यर्थ है, जबकि डेमेटर मानता है कि तर्क इसके लिए माइग्रेट कर सकता है रिफैक्टरिंग के माध्यम से सबसे प्राकृतिक जगह।

हालांकि, आप तर्क दे सकते हैं कि आरईएसटी केवल एक स्टॉप-गैप है जब तक आप अपने ग्राहकों को बेहतर समझ नहीं लेते। क्या आरईएसटी सिर्फ एक हैक है? क्या किसी भी सर्वर/क्लाइंट परिदृश्य में डेमेटर अवास्तविक है?

Answer 1

• क्या किसी भी सर्वर/ग्राहक परिदृश्य में डेमेटर अवास्तविक है?

मुझे लगता है कि आपने यहां अपने प्रश्न का उत्तर दिया है। REST इस संबंध में SOAP या XML-RPC से अलग तरीके से कैसे है?

REST की बात सुपर ढीला संयोजन प्रदान करने के लिए नहीं है, लेकिन निम्नलिखित:

• एक पहचानकर्ता जो सटीक वर्णन करता संसाधन अनुरोध किया जा रहा प्रदान करें।
• सेवाओं जो व्यवहार करते हैं जैसा कि उम्मीद की GET अनुरोध idempotent हैं प्रदान करें, PUT अद्यतन रिकॉर्ड, POST बनाता है, DELETE हटाता
• राज्य को कम से कम सर्वर
• पर संग्रहीत किया जा रहा अनावश्यक जटिलता

मामलों में जहां हैं नीचे आंसू REST सबसे अच्छा जवाब नहीं है, लेकिन REST सामान्य रूप से उल्लेखनीय रूप से अच्छी तरह से काम करता है।

Answer 2

मैं उस कानून/सुझाव का कोई भी ध्यान नहीं देता हूं। यह एकत्रीकरण और संरचना के आधे लाभ को हरा देता है, और मेरे पास यह नहीं होगा।

Answer 3

मुझे लगता है कि वे वास्तव में ऑर्थोगोनल हैं। आरईएसटी यूआरआई द्वारा कैननिकल तरीकों के सेट के साथ संबोधित संसाधनों के संग्रह का वर्णन करता है: प्राप्त करें, पोस्ट करें, आदि। यदि आरईएसटी दिनचर्या एक यूआरआई लौटाती है, तो यह "विधि तक पहुंचने" नहीं है, यह एक ही विधि के साथ एक अलग वस्तु की पहचान कर रहा है।

Answer 4

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

उदा। ऑब्जेक्ट उन्मुख परिदृश्य में, आप a.b.c को कॉल के साथ प्रतिस्थापित कर सकते हैं।

<a> 
    <link href="bc"/> 
</a> 

बजाय

GET a 

    <a> 
     <link href="b"/> 
    </a> 

GET b 

    <b> 
     <link href="c"/> 
    </b> 

GET c 

कर रहा altCognito से सहमत नहीं है और कहते हैं कि बाकी के मुख्य लक्ष्यों में से एक है कि होगा: बीसी

एक RESTful प्रतिनिधित्व में आप निम्नलिखित बना सकते हैं ढीला युग्मन। वर्दी इंटरफेस, मानक मीडिया प्रकार और हेटोएस सभी एक बेहद कमजोर युग्मित इंटरफेस का उत्पादन करने के लिए गठबंधन करते हैं।

डेविड की टिप्पणी के जवाब में:

बाकी बिंदु जहां यह व्यर्थ प्रदाता ग्राहकों की सभी जरूरतों को अनुमान लगाने की कोशिश करने के लिए के लिए है करने के लिए सुपर ढीला संयोजन के बारे में सब

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