2012-12-17 31 views
10

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

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

फिर AJAX गेम में शामिल हो गया और वेब-एप्लिकेशन सर्वर और ब्राउज़र के बीच रहने वाली किसी चीज़ में बदलना शुरू कर दिया।

AJAX के चरम सीमा के दौरान, वेब-एप्लिकेशन तर्क पूरी तरह से ब्राउज़र पर लाइव होना शुरू कर दिया। मुझे लगता है कि यह तब था जब HTTP रीस्टफुल एपीआई उभरना शुरू कर दिया था। अचानक हर नई सेवा में दयालु रीस्टफुल एपीआई, और अचानक जावास्क्रिप्ट एमवी * ढांचे पॉपकॉर्न की तरह पॉपिंग शुरू कर दिया। मोबाइल उपकरणों का उपयोग भी काफी बढ़ गया है, और आरईएसटी इस तरह के परिदृश्यों के लिए बस महान है। मैं यहां "तरह का भरोसेमंद" कहता हूं क्योंकि लगभग हर एपीआई जो आरईएसटी होने का दावा करती है, वह नहीं है। लेकिन यह एक पूरी तरह से अलग कहानी है।

असल में, मैं एक प्रकार का "आरईएसटी प्रचारक" बन गया।

जब मैंने सोचा कि वेब-एप्लिकेशन अधिक विकसित नहीं हो पा रहे हैं, तो एक नया युग शुरू हो रहा है: राज्यव्यापी लगातार कनेक्शन वेब-एप्लिकेशन। Meteor उस तरह के अनुप्रयोगों के एक शानदार ढांचे का एक उदाहरण है। तब मैंने यह video देखा। इस वीडियो में मैट डेबर्गलिस ने उल्का के बारे में बात की और दोनों शानदार काम करते हैं! हालांकि वह लगातार वास्तविक समय कनेक्शन के पक्ष में इस तरह के उद्देश्यों के लिए आरईएसटी एपीआई को कम करने का है।

मुझे वास्तविक समय मॉडल अपडेट होना बहुत पसंद है, उदाहरण के लिए, लेकिन अभी भी सभी आरईएसटी उत्कृष्टता है। स्ट्रीमिंग आरईएसटी एपीआई मुझे जो चाहिए (प्रतीत होता है कि फ़ायरहोज.ओ और ट्विटर की एपीआई, उदाहरण के लिए), लेकिन इस नए प्रकार के एपीआई पर बहुत कम जानकारी है।

तो मेरे सवाल है:

वेब आधारित वास्तविक समय संचार बाकी प्रतिमान के साथ असंगत है?

(लंबे परिचयात्मक पाठ के लिए क्षमा करें, लेकिन मैंने सोचा था कि इस सवाल का केवल कुछ संदर्भ के साथ कोई मतलब होता है) आप के रूप में कर रहे हैं महान है, जब तक वेब अनुप्रयोगों के लिए

उत्तर

3

स्टेटफुल लगातार टीसीपी/आईपी कनेक्शन चारों ओर नहीं जा रहे हैं।

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

जब आईपी पते बदलते रहते हैं, तो धारणा है कि यह एक सतत कनेक्शन है, बल्कि जल्दी से वाष्पित हो जाता है।

रीयल-टाइम वेब-ऐप के लिए ढांचे को इस धारणा के साथ आर्किटेक्टेड किया जाना चाहिए कि कनेक्शन क्षणिक होंगे और ढांचे को सत्र की अपनी धारणा को लागू करना होगा जबकि बैक-एंड के अंतर्निहित आईपी कनेक्शन बदलते रहेंगे।

क्लाइंट और सर्वर के बीच सभी अनुरोधों और प्रतिक्रियाओं में एक सत्र को परिभाषित और उपयोग करने के बाद, एक अनिवार्य रूप से 'वेब कनेक्शन' होता है। और अब, कोई आरईएसटी प्रतिमान का उपयोग कर रीयल-टाइम वेब आधारित ऐप्स विकसित कर सकता है।

ढांचे के बैक-एंड सर्वर को अद्यतनों को कतार में रखना बुद्धिमान होना चाहिए, जबकि आईपी पते संक्रमण से गुज़र रहे हैं और फिर टीसीपी/आईपी कनेक्शन फिर से स्थापित होने पर सिंक-अप होना चाहिए।

संक्षिप्त उत्तर है, 'हाँ, आप रीस्ट-टाइम वेब आधारित ऐप आरईएसटी प्रतिमान का उपयोग कर कर सकते हैं'।

यदि आप एक के साथ खेलना चाहते हैं, तो मुझे बताएं।

+1

REST हमें बताता है कि प्रत्येक अनुरोध में सभी आवश्यक जानकारी होनी चाहिए ताकि सर्वर स्टेटलेस हो और प्रत्येक अनुरोध को समान रूप से मान सके। यह मुख्य विशेषता है जो आरईएसटी वेब सेवाओं में स्केलेबिलिटी को सक्षम बनाता है। कोई सत्र नहीं है। क्या आपको लगता है कि सर्वर अभी भी निरंतर कनेक्शन (वेबसाकेट या http लंबे मतदान, उदाहरण के लिए) के साथ स्टेटलेस हो सकता है? – miguelcobain

+0

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

2

मुझे इस विषय में बहुत दिलचस्पी है।

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

मैं नहीं कह रहा हूँ उल्का खराब, डिज़ाइन किया गया है क्योंकि मैं उल्का के बारे में ज्यादा पता नहीं है: इस पोस्ट के कागजात के लिए कुछ लिंक है कि खराब से डिजाइन आरपीसी के साथ मुसीबतों का कुछ के बारे में बात की है।

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

और, मैं इस "वास्तविक समय" वेब क्रांति में भी पीछे नहीं जाना चाहता! यह निश्चित रूप से बहुत ही भयानक है।

अगर वहाँ एक संकर दृष्टिकोण है कि काम कर सकते हैं नहीं है मैं सोच रहा हूँ:

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

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

जहां तक ​​आरईएसटी-संगत है, मुझे विश्वास है कि यह दृष्टिकोण किया गया है (हालांकि मुझे इस स्ट्रीमिंग पक्ष के बारे में निश्चित नहीं है), मुझे याद नहीं है कि यह http://shop.oreilly.com/product/9780596805838.do (अभ्यास में आरईएसटी) में था, या क्यूकॉन 2010: http://www.infoq.com/presentations/RESTful-SOA-DDD में इस रिकॉर्ड की गई बातचीत में मैंने एक प्रस्तुति में वॉन वर्नॉन द्वारा सुना।

वह इस तरह एक URI डिजाइन कुछ के बारे में बात (मैं बिल्कुल याद नहीं है)

मेजबान/संस्था < - एक संसाधन के वर्तमान संस्करण मेजबान/संस्था/घटनाओं < - घटनाओं है की सूची अपनी वर्तमान स्थिति में वस्तु उत्परिवर्तित हुआ

उदाहरण:

मेजबान/संस्था/घटनाओं/1 < - इस इकाई मेजबान/संस्था/घटनाओं/2 < के निर्माण के लिए अनुरूप होगा - यह कोर होगा इकाई के खिलाफ कभी दूसरी घटना का जवाब

उन्होंने यह भी हो सकता है इतिहास के लिए वहाँ कुछ था, पूरा monent-इन-टाइम राज्य, जैसे:

मेजबान/संस्था/संस्करण/2 < - यह होगा उपरोक्त घटना 2 के बाद इकाई की पूरी स्थिति बनें।

वॉन ने हाल ही में एक पुस्तक प्रकाशित की, कार्यान्वयन डोमेन संचालित डिजाइन है, जो सामग्री तालिका से यह कैसा दिखता को शामिल किया गया बाकी और घटना चालित वास्तुकला: http://www.amazon.com/gp/product/0321834577

+1

लिंक के लिए और आपके उत्तर के लिए धन्यवाद। मेरा मानना ​​है कि मैं आपके जैसी स्थिति में हूं। मैं आरईएसटी का उपयोग करने के लिए पुराने फैशन बनना नहीं चाहता। दोनों चीजों को संयोजित करने का एक तरीका होना चाहिए। Http://firehose.io/ देखें। मैं सावधानीपूर्वक मूल्यांकन करूंगा कि यह इस समस्या को कैसे संबोधित करता है। मुझे लगता है कि यह एक लायक है। – miguelcobain

+0

मैं पूरी तरह से फायरहोज की जांच करने जा रहा हूं।io, होम पेज पर मूल सारांश पढ़ने के बाद। लिंक के लिए धन्यवाद! – JoshGough

+0

यह Firehose.io से संबंधित एक अच्छी प्रस्तुति है: http://confreaks.com/videos/870-railsconf2012-realtime-web-plplications-with-streaming-rest – JoshGough

0

मैं http://firehose.io/ के लेखक हूँ, एक वास्तविक समय ढांचा आधारित इस आधार पर कि स्ट्रीमिंग रीस्टफुल एपीआई स्ट्रीम कर सकते हैं और मौजूद होना चाहिए। परियोजना वेबसाइट से:

Firehose जटिल प्रोटोकॉल के बिना वास्तविक समय वेब क्षुधा बना रहे हैं या खरोंच से अपने अनुप्रयोग को फिर से लिखने की एक न्यूनतम इनवेसिव तरीका है। इसका गंदगी सरल पब/सब सर्वर है जो में क्लाइंट-साइड जावास्क्रिप्ट मॉडल को वेबसाकेट या HTTP लंबे मतदान के माध्यम से सर्वर कोड के साथ सिंक करता है। यह पूरी तरह से विश्वसनीय डिजाइन पैटर्न को गले लगाता है, जिसका अर्थ है कि आप अपना एप बनाने के बाद एक अच्छा एपीआई समाप्त कर देंगे।

यह मेरी आशा है कि यह ढांचा इंटरनेट को आरपीसी अंधेरे युग में वापस जाने से रोकता है, लेकिन हम देखेंगे कि क्या होता है। हम उत्पादन में Firehose.io का उपयोग Poll Everywhere पर करते हैं ताकि विभिन्न उपकरणों के सभी प्रकार के लोगों को लाखों संदेश प्रतिदिन धक्का दे सकें। यह काम करता हैं।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^