सवाल WebSockets उपलब्ध होने पर AJAX का उपयोग क्यों करें?


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

हालांकि प्रोजेक्ट शुरू करने के बाद से मैंने सुरक्षा की कमी के बारे में पढ़ा है, और कुछ ब्राउज़र डिफ़ॉल्ट रूप से वेबसाकेट अक्षम करने का विकल्प चुनते हैं ..

यह मुझे सवाल पर ले जाता है:

AJAX का उपयोग क्यों करें जब WebSockets विलंबता और संसाधन ओवरहेड को कम करने का इतना अच्छा काम करता है, क्या ऐसा कुछ भी है जो AJAX WebSockets से बेहतर करता है?


161
2018-04-30 01:02


मूल


यहां वेब सॉकेट का समर्थन करने वाले इंजनों की एक सूची दी गई है। en.wikipedia.org/wiki/... - Dante
कुछ संख्याएं: blog.arungupta.me/rest-vs-websocket-comparison-benchmarks - Rune Jeppesen


जवाब:


वेबसाकेट्स का उद्देश्य AJAX को प्रतिस्थापित करने का नहीं है और धूमकेतु / लंबे मतदान के लिए सख्ती से प्रतिस्थापन नहीं है (हालांकि ऐसे कई मामले हैं जहां यह समझ में आता है)।

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

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

यदि आपको वेबसाकेट्स द्वारा प्रदान किए जाने वाले विशिष्ट लाभों की आवश्यकता नहीं है, तो संभवत: एजेक्स और धूमकेतु जैसी मौजूदा तकनीकों के साथ रहना बेहतर विचार है क्योंकि इससे आपको टूल, टेक्नोलॉजीज, सुरक्षा तंत्र के विशाल विद्यमान पारिस्थितिक तंत्र के साथ पुन: उपयोग और एकीकृत करने की अनुमति मिलती है। , ज्ञान के आधार (यानी स्टैक ओवरफ्लो पर कहीं अधिक लोग वेबस्केट्स से HTTP / अजाक्स / धूमकेतु जानते हैं), आदि

दूसरी तरफ, यदि आप एक नया एप्लीकेशन बना रहे हैं जो विलंबता और HTTP / अजाक्स / धूमकेतु की कनेक्शन बाधाओं के भीतर अच्छी तरह से काम नहीं करता है, तो वेबस्केट का उपयोग करने पर विचार करें।

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

अद्यतन करें: आईओएस 6 अब मौजूदा हाइबी / आईईटीएफ 6455 मानक का समर्थन करता है।


189
2018-04-30 18:34



और अब 2014 की शुरुआत में, वेबसाकेट व्यावहारिक रूप से एक मानक (आरएफसी 6455) है और केवल ओपेरा मिनी इसका समर्थन नहीं करता है। - Dirk Bester
सच है, ओपेरा मिनी इसका समर्थन नहीं करता है लेकिन अधिक शर्मनाक है एंड्रॉइड ब्राउज़र के समर्थन की कमी जो वेबव्यू आधारित ऐप्स (कॉर्डोवा फोनगैप) के साथ उपयोग करने के लिए थोड़ा अधिक जटिल है। - Miles M.
@kanaka, HTTP (AJAX, धूमकेतु) की तुलना में WebSocket पर फ़ाइलों को तेजी से या धीमी गति से भेज रहा है? - Pacerier
@ कानाका, अगर उनमें से दोनों बड़ी फाइलें समान रूप से अच्छी तरह से करते हैं, तो क्यों न केवल वेबकॉकेट के माध्यम से सब कुछ भेजें? WebSockets के माध्यम से सब कुछ भेजा जा सकता है जब AJAXing पृष्ठों / डेटा परेशान क्यों? (मान लीजिए कि यह पहले से ही 2020 है और सभी ब्राउज़रों को वेबसाकेट्स के लिए समर्थन है) - Pacerier
@Pacerier एक पूर्ण उत्तर लंबा होगा, लेकिन यह मूल रूप से इस तथ्य को उबालता है कि आप उन चीजों को फिर से कार्यान्वित करने की कोशिश कर रहे हैं जो ब्राउज़र पहले से ही अच्छा कर रहा है (कैशिंग, सुरक्षा, समांतरता, त्रुटि प्रबंधन, आदि)। प्रदर्शन के संबंध में, हालांकि कच्चे बड़े फ़ाइल स्थानांतरण की गति से स्क्रैच समान होगा, ब्राउज़रों के पास वेब सामग्री के कैशिंग को बारीकी से ट्यून करने के लिए सालों हैं (जिनमें से अधिकांश AJAX अनुरोधों पर लागू होते हैं) इसलिए व्यावहारिक रूप से, AJAX से WebSockets पर स्विच करने की संभावना बहुत अधिक नहीं है मौजूदा कार्यक्षमता के लिए लाभ। लेकिन कम विलंबता द्वि-दिशात्मक संचार के लिए यह एक बड़ी जीत है। - kanaka


दिसम्बर 2017 तक फास्ट फॉरवर्ड, Websockets (व्यावहारिक रूप से) हर ब्राउज़र द्वारा समर्थित हैं और उनका उपयोग बहुत आम है।

हालांकि, इसका मतलब यह नहीं है कि Websockets कम से कम पूरी तरह से नहीं, विशेष रूप से HTTP / 2 अनुकूलन के रूप में AJAX को बदलने में कामयाब रहे।

संक्षिप्त जवाब यह है कि AJAX अभी भी अधिकांश आरईएसटी अनुप्रयोगों के लिए बहुत अच्छा है, यहां तक ​​कि Websockets का उपयोग करते समय भी। लेकिन भगवान विवरण में है, तो ...:

मतदान के लिए AJAX?

मतदान (या लंबे मतदान) के लिए AJAX का उपयोग मर रहा है (और यह होना चाहिए), लेकिन यह अभी भी दो अच्छे कारणों (मुख्य रूप से छोटे वेब ऐप्स के लिए) के उपयोग में है:

  1. कई डेवलपर्स के लिए, AJAX कोड को आसान बनाता है, खासकर जब बैकएंड को कोडिंग और डिज़ाइन करने की बात आती है।

  2. HTTP / 2 के साथ, AJAX से संबंधित उच्चतम लागत (एक नए कनेक्शन की स्थापना) को समाप्त कर दिया गया था, जिससे AJAX कॉल काफी प्रदर्शन करने की अनुमति देता है, खासकर डेटा पोस्ट करने और अपलोड करने के लिए।

तथापि, वेबस्केट पुश AJAX से कहीं बेहतर है (हेडर को दोबारा प्रमाणित या पुनः भेजने की आवश्यकता नहीं है, "कोई डेटा" राउंडट्रिप्स आदि की आवश्यकता नहीं है)। इस चर्चा की गई थी कई बार।

आरईएसटी के लिए AJAX?

AJAX के लिए एक बेहतर उपयोग आरईएसटी एपीआई कॉल है। यह उपयोग कोड बेस को सरल बनाता है और वेबसाइकिल कनेक्शन को अवरुद्ध करने से रोकता है (विशेष रूप से मध्यम आकार के डेटा अपलोड पर)।

बहुत सारे हैं आरईएसटी एपीआई कॉल के लिए AJAX पसंद करने के लिए आकर्षक कारण और डेटा अपलोड:

  1. AJAX एपीआई व्यावहारिक रूप से आरईएसटी एपीआई कॉल के लिए डिज़ाइन किया गया था और यह एक बहुत अच्छा फिट है।

  2. AJAX का उपयोग कर आरईएसटी कॉल और अपलोड क्लाइंट और बैकएंड दोनों पर कोड के लिए काफी आसान हैं।

  3. डेटा पेलोड बढ़ने के साथ ही, जब तक संदेश विखंडन / मल्टीप्लेक्सिंग तर्क कोडित नहीं किया जाता है, तब तक वेबस्केट कनेक्शन अवरुद्ध हो सकते हैं।

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

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

हालांकि, बड़ी परियोजनाओं पर, Websockets द्वारा प्रदान की गई लचीलापन और कोड जटिलता और संसाधन प्रबंधन के बीच संतुलन वेबसाइटों के पक्ष में संतुलन को सूचित करेगा।

उदाहरण के लिए, वेबसाइटों के आधार पर अपलोड किए जाने के बाद वेबबॉकेट आधारित अपलोड बड़े अपलोड को फिर से शुरू करने की क्षमता प्रदान कर सकते हैं (पुनः याद रखें कि 5 जीबी मूवी जिसे आप अपलोड करना चाहते हैं?)।

अपलोड विखंडन तर्क को कोडिंग करके, एक बाधित अपलोड फिर से शुरू करना आसान है (कठिन हिस्सा चीज़ को कोडिंग कर रहा था)।

HTTP / 2 पुश के बारे में क्या?

मुझे शायद यह जोड़ना चाहिए कि HTTP / 2 पुश सुविधा वेबसाइट्स को प्रतिस्थापित नहीं करती है (और शायद नहीं)।

यह किया गया था यहां चर्चा की इससे पहले, लेकिन यह उल्लेख करने के लिए पर्याप्त है कि एक एकल HTTP / 2 कनेक्शन पूरे ब्राउज़र (सभी टैब / विंडोज़) परोसता है, इसलिए HTTP / 2 द्वारा धक्का दिया जा रहा डेटा यह नहीं जानता कि यह कौन सा टैब / विंडो है, जो इसे बदलने की क्षमता को समाप्त कर रहा है वेबसाइटों को डेटा को सीधे एक विशिष्ट ब्राउज़र टैब / विंडो पर धक्का देने की क्षमता।

जबकि वेबसाइट्स छोटे द्वि-दिशात्मक डेटा संचार के लिए बहुत अच्छे हैं, एजेक्स ने अभी भी कई फायदे किए हैं - खासकर जब बड़े पेलोड (अपलोड इत्यादि) पर विचार करते हैं।

और सुरक्षा?

खैर, आम तौर पर, एक प्रोग्रामर को अधिक विश्वास और नियंत्रण प्रदान किया जाता है, उपकरण जितना अधिक शक्तिशाली होता है ... और अधिक सुरक्षा चिंताओं को उखाड़ फेंक देता है।

प्रकृति द्वारा AJAX का ऊपरी हाथ होगा, क्योंकि इसकी सुरक्षा ब्राउज़र के कोड में बनाई गई है (जो कभी-कभी संदिग्ध होती है, लेकिन यह अभी भी वहां है)।

दूसरी तरफ, AJAX कॉल "बीच में आदमी" हमलों के लिए अधिक संवेदनशील हैं, जबकि वेबसाइट्स सुरक्षा समस्याएं आमतौर पर एप्लिकेशन कोड में बग होती हैं जो सुरक्षा दोष पेश करती हैं (आमतौर पर बैकएंड प्रमाणीकरण तर्क वह है जहां आपको ये मिलेंगे)।

व्यक्तिगत रूप से मुझे यह नहीं लगता कि यह एक बड़ा अंतर है, अगर मुझे लगता है कि वेबसाइटॉक थोड़ा बेहतर है, खासकर जब आप जानते हैं कि आप क्या कर रहे हैं।

मेरी विनम्र राय

आईएमएचओ, मैं सब कुछ के लिए Websockets का उपयोग करता हूं लेकिन आरईएसटी एपीआई कॉल करता हूं। बड़े डेटा अपलोड मैं टुकड़े कर दूंगा और जब संभव हो तो Websockets पर भेज देंगे।

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


32
2017-12-22 18:40



छोटे व्याकरण त्रुटि 'अगर कुछ भी मैं बात करता हूं ...' सोचो - spottedmahn
@spottedmahn - धन्यवाद! मुझे लगता है कि ऐसा होता है कि मैं अपने कोड संपादक का मसौदा पाठ का उपयोग करता हूं - Myst
माफ़ी, जब बाउंटी की समयसीमा समाप्त हो गई तो मैं अनुपस्थित था। मेरे हिस्से पर खराब योजना। मैंने 23 घंटे की समाप्ति के बाद आपको एक और उपहार दिया है जो मैं आपको दूंगा। - Duncan Jones
धन्यवाद, @ डंकन जोन्स! - Myst
@Myst इस महान स्पष्टीकरण के लिए धन्यवाद। लाइव नोटिफिकेशन जैसे एफबी / स्टैक ओवरफ्लो के लिए आप क्या पसंद करेंगे? मैं अपने वेब एप्लिकेशन के लिए एक रेस्टफुल वेबसाइसेस डिज़ाइन कर रहा हूं, लेकिन बहुत उलझन में मुझे अधिसूचना सुविधा के लिए क्या उपयोग करना चाहिए? AJAX या WebSockets? - TheCoder


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

सालों से गुजरने के साथ, वेबसाकेट अधिक से अधिक समर्थित होंगे, लेकिन इस बीच आपके पास ब्राउज़र में डेटा भेजने के लिए हमेशा एक HTTP- आधारित फॉल-बैक विधि होनी चाहिए।


16
2018-04-30 09:20



सौभाग्य से अधिकांश वेबसॉकेट ढांचे के समर्थन ने फ्लैश के लिए फ्लैश का उपयोग करने सहित फॉलबैक कहा। Socketn.IO और सिग्नल दोनों सभ्य ढांचे हैं ... हालांकि आप वास्तव में सीमित हैं, जैसा कि आप प्रॉक्सी और लोड बैलेंसर्स के कारण उल्लेख करते हैं। सौभाग्य से, नोड.जेएस और अगले आईआईएस दोनों इस भूमिका के साथ एक सभ्य नौकरी भी करते हैं। - Tracker1
उत्सुक: कौन से वाहक पोर्ट 80 पर वेबस्केट को अवरुद्ध करते हैं? पोर्ट 443 पर कौन सा ब्लॉक सुरक्षित वेबसॉकेट (डब्ल्यूएसएस)? उत्तरार्द्ध बलपूर्वक, पारदर्शी एमआईटीएम वेब प्रॉक्सी का तात्पर्य है .. सार्वजनिक नेटवर्क (केवल कॉर्पोरेट वाले) में कभी नहीं देखा, क्योंकि इसे ब्राउज़र में नए सीए कर्ट स्थापित करने की आवश्यकता है। - oberstet
वर्तमान में, उदाहरण के लिए, वोडाफोन इटली पोर्ट 80 पर डब्ल्यूएस ब्लॉक करता है, लेकिन पोर्ट 443 पर डब्ल्यूएसएस को अनुमति देता है। आप हमारे होम पेज के माध्यम से आसानी से किसी भी वाहक का परीक्षण कर सकते हैं, जिसे आप HTTP और HTTPS दोनों में एक्सेस कर सकते हैं। यह वेबसाकेट की कोशिश करता है और अगर वे अवरुद्ध होते हैं तो HTTP पर वापस आते हैं। इस यूआरएल का उपयोग मध्य में एक विजेट प्रदर्शित करने के लिए करें जो वर्तमान परिवहन की रिपोर्ट करता है: lightstreamer.com/?s - Alessandro Alinone


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


14
2018-02-19 17:13





वेबसाकेट पुराने वेब ब्राउज़र में काम नहीं करते हैं, और जो इसे समर्थन करते हैं अक्सर अलग कार्यान्वयन होते हैं। यह बहुत ही अच्छा कारण है कि क्यों वे AJAX के स्थान पर हर समय उपयोग नहीं किए जाते हैं।


9
2018-04-30 01:04



एक बेहतर कारण यह है कि एक AJAX अनुरोध एक सामान्य HTTP अनुरोध है जिसका अर्थ है कि यह HTTP संसाधनों को पुनर्प्राप्त कर सकता है; WebSockets ऐसा नहीं कर सकते हैं। - Dan D.
@Dan क्या होगा यदि उदाहरण के लिए छवि फ़ाइलों को बेस 64 के रूप में भेजा जाता है, सीएसएस को टेक्स्ट के रूप में भेजा जाता है, जावास्क्रिप्ट भी पाठ के रूप में और फिर दस्तावेज़ में जोड़ा जाता है? क्या यह व्यवहार्य होगा? - Jack
@DanD। +1, मैं मानता हूं, मुझे लगता है कि मैं प्रश्न के उदाहरण के रूप में तेजी से स्ट्रीमिंग डेटा के संदर्भ से अधिक प्रश्न पूछ रहा था, लेकिन यह निश्चित रूप से सही है। - jli
@ डैन डी - कभी-कभी आप उस बकवास को लाइन पर जाने के लिए नहीं चाहते हैं, जैसे कुकीज और हेडर ... - vsync
@DanD।, HTTP और WebSocket दो अलग-अलग प्रोटोकॉल हैं, बेशक हम वेबसाकेट प्रोटोकॉल का उपयोग कर HTTP संसाधनों का अनुरोध नहीं कर सकते हैं, उसी कारण से हम HTTP प्रोटोकॉल का उपयोग कर वेबसॉकेट संसाधनों का अनुरोध नहीं कर सकते हैं! इसका मतलब यह नहीं है कि क्लाइंट वेबसाईट प्रोटोकॉल के माध्यम से भेजी गई HTML और / या छवि फ़ाइलों का अनुरोध नहीं कर सकता है। - Pacerier


मुझे नहीं लगता कि हम Websockets और HTTP की स्पष्ट तुलना कर सकते हैं क्योंकि वे कोई प्रतिद्वंद्वियों नहीं हैं और न ही एक ही समस्या का समाधान करते हैं।

वेबसाइकिल लंबी अवधि के बिडरेक्शनल डेटा स्ट्रीमिंग को वास्तविक समय के तरीके में संभालने के लिए एक बेहतरीन विकल्प है, जबकि आरईएसटी कभी-कभी संचार के लिए बहुत अच्छा है। Websockets का उपयोग करना काफी निवेश है, इसलिए यह कभी-कभी कनेक्शन के लिए एक ओवरकिल है।

आप पाते हैं कि उच्च लोड मौजूद होने पर वेबसाइटॉक बेहतर होते हैं, कुछ मामलों में HTTP थोड़ा तेज होता है क्योंकि यह कैशिंग का उपयोग कर सकता है। Websockets के साथ आरईएसटी की तुलना करना संतरे से सेब की तुलना करना है।

हमें यह जांचना चाहिए कि कौन सा हमारे आवेदन के लिए बेहतर समाधान प्रदान करता है, जो हमारे उपयोग के मामले में सबसे अच्छा फिट बैठता है।


1
2017-12-27 10:57



प्रश्न सामान्य रूप से AJAX के बारे में था, विशेष रूप से आरईएसटी नहीं। यह सच है कि AJAX का उपयोग आरईएसटी के लिए किया जा सकता है, लेकिन इसका उपयोग मतदान और लंबी मतदान के लिए भी किया जाता है। हालांकि मैं आपके निष्कर्ष से सहमत हूं (जैसा कि आप मेरे उत्तर से बता सकते हैं), मुझे लगता है कि आपका उत्तर भेद को प्रतिबिंबित कर सकता है (ध्यान दें कि वेबकॉकेट का उपयोग आरईएसटी के लिए भी किया जा सकता है, हालांकि HTTP विधियों का उपयोग करके नहीं)। - Myst
@ मिस्ट मैं आपसे सहमत हूं। - Gaurav Gandhi


क्लाइंट-साइज लिब के रूप में HTTP और Websockets के बीच अंतर का एक उदाहरण जो आरईएसटी एपीआई जैसे वेबस्केट एंडपॉइंट और क्लाइंट पर वेबसाइट्स जैसे रीस्टफुल एंडपॉइंट्स को संभाल सकता है। https://github.com/mikedeshazer/sockrest साथ ही, उन लोगों के लिए जो क्लाइंट पर वेबसाईट एपीआई का उपभोग करने की कोशिश कर रहे हैं या इसके विपरीत जिस तरह से उनका उपयोग किया जाता है। Libs / sockrest.js बहुत अधिक अंतर को स्पष्ट करता है (या बल्कि माना जाता है)।


0
2018-06-07 04:40