आरईएसटी

Question

में इवेंट आधारित इंटरैक्शन शैली मैं वर्तमान में आरईएसटी से जुड़े एक डिजाइन मुद्दे के साथ संघर्ष कर रहा हूं। जिस एप्लिकेशन को मैं डिजाइन कर रहा हूं उसे घटनाओं को भेजने और बातचीत की पब/उप शैली का समर्थन करने की आवश्यकता है। मैं आरईएसटी की "स्टेटलेस इंटरैक्शन" बाधा को तोड़ने के बिना इन इंटरैक्शन शैली को प्रदान करने के लिए एक डिज़ाइन के साथ आने में असमर्थ हूं। मैं मतदान के खिलाफ नहीं हूं क्योंकि कुछ लोग (मतदान बेकार) लगते हैं, लेकिन मेरा आवेदन एक घटना आधारित और पब/उप-शैली की शैली की मांग करता है (मतदान मेरे लिए एक विकल्प नहीं है)। तो, मेरा सवाल है:

1. क्या मैं एक विश्वसनीय एप्लिकेशन तैयार कर सकता हूं जो REST contraint को तोड़ने के बिना ईवेंट आधारित और पब/उप इंटरैक्शन का समर्थन करता है?
2. क्या आरईएसटी शैली इस प्रकार की बातचीत शैली के लिए उपयुक्त है?

Answer 1

मैं डंकन क्रैग द्वारा Distributed Observer Pattern को एक अच्छी पढ़ाई के रूप में अनुशंसा करता हूं (थोड़ा मुश्किल है लेकिन प्रयास के लायक है)।

जैसा कि अन्य ने इसकी संभावना का संकेत दिया है, आपको मतदान का उपयोग करने की आवश्यकता होगी, लेकिन जैसा कि आप सही कह रहे हैं कि ग्राहक अपनी रुचि (सदस्यता बनाने के लिए पोस्ट) पंजीकृत कर सकते हैं।आप अपने स्वयं के संसाधन के रूप में सदस्यता देखते हैं, तो प्रकाशक और ग्राहक के बीच एक अनुबंध है, तो मैं इसे एक को तोड़ने बाकी की कमी के रूप में देखने नहीं होगा (आवेदन और के बीच अंतर के लिए राज्य और statelessnessRESTful Web Services के पेज 217 पर देख संसाधन राज्य)

Answer 2

मुझे कोई कारण नहीं दिख रहा है कि क्यों विश्वसनीय इंटरफेस घटनाओं का समर्थन नहीं करना चाहिए।

इसे मतदान के माध्यम से किया जाना चाहिए, आपको दिमाग; और यह सच होगा भले ही आप इसके बजाय SOAP का उपयोग करना चाहते थे।

जबकि आपके वेब सर्वर निश्चित रूप से स्टेटलेस बने रहेंगे, तो संभवतः आपके पास पिछली छोर पर कहीं डीबी है। आप सदस्यता तालिका जोड़कर घटनाओं के लिए सदस्यता को संभालने के लिए इस डीबी का उपयोग कर सकते हैं।

Answer 3

मुझे लगता है कि सर्वर का मतलब है कि सर्वर को घटनाओं के बारे में ग्राहकों को सूचित करना चाहिए। मैं नहीं देखता कि विशिष्ट तकनीक यहां कैसे मायने रखती है: आपको एक ही समस्या का सामना करना पड़ेगा, और आरईएसटी, एसओएपी-आधारित वेब सेवाओं या किसी अन्य विकल्प का उपयोग किए बिना, उसी पूल से समाधान लेना होगा।

मूल प्रश्न यह है कि क्या आपका सर्वर कनेक्शन शुरू कर सकता है? इसे पूरक, क्या ग्राहक एक बंदरगाह सुन सकते हैं? यदि ऐसा है, तो ग्राहक पंजीकृत (उप), और सर्वर घटनाओं (पब) की सूचना देता है। पंजीकरण ऑपरेशन और अधिसूचना कार्यक्रम दोनों ही भरोसेमंद हो सकते हैं।

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

और बेशक, मतदान पुन: भरोसा किया जा सकता है।

Answer 4

Here रॉय द्वारा विषय पर एक चर्चा है।

Answer 5

बस बाकी की कमी पर एक तेजी से जांच:

• क्लाइंट-सर्वर वास्तुकला
• राज्यविहीन
• कैश
• समान अंतरफलक
  • संसाधन की पहचान
  • संसाधन का निरूपण के माध्यम से हेरफेर
  • आत्म desriptive संदेशों
  • आवेदन राज्य के इंजन
• बहुस्तरीय प्रणाली
की हाइपरमीडिया
• मांग पर कोड (वैकल्पिक)

फील्डिंग शोध प्रबंध से:

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

बीटीडब्ल्यू। एक घटना आधारित प्रणाली शायद अधिकांश बाधाओं का उल्लंघन करेगी। यह ग्राहकों के बिना hypermedia the engine of application state तरह बातें परिभाषित करना कठिन है (के बाद से application state के अन्य नाम client state है) और हाइपरलिंक (क्योंकि वे पब/उप द्वारा व्यर्थ कर रहे हैं), और इतने पर ...

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

2016.05.15 अपडेट करें।

जहां तक ​​मैं समझता हूँ कि ग्राहक - सर्वर वास्तुकला - फील्डिंग here और अपने शोध प्रबंध में here का वर्णन करता है - हमेशा अनुरोध/REP संचार का उपयोग करता है। ग्राहक अनुरोध भेजता है और आरईएसटी सेवा जवाब देता है। यदि आप क्लाइंट - सर्वर बाधा के उल्लंघन के बिना PUB/SUB की तरह कुछ करना चाहते हैं, तो ऐसा करने का एकमात्र तरीका मतदान का उपयोग है। यदि आप मतदान का उपयोग नहीं करना चाहते हैं, तो ओएससी। आप एक आरईएसटी सेवा और एक वेबसाइकिल सेवा का एक साथ उपयोग कर सकते हैं, यह प्रतिबंधित नहीं है ...

Answer 6

वेबहुक इस समस्या का उत्तर हैं। वे आरईएसटी सिद्धांतों का उल्लंघन किये बिना घटनाओं की अनुमति देते हैं।