REST API को बदलने के लिए Websocket API?

Question

मेरे पास एक एप्लिकेशन है जिसका प्राथमिक कार्य वेबसैट या लंबे मतदान के माध्यम से वास्तविक समय में काम करता है।

हालांकि, अधिकांश साइट एक रेस्टफुल फैशन में लिखी गई है, जो भविष्य में एप्लिकेशन एस और अन्य ग्राहकों के लिए अच्छा है। हालाँकि, मैं REST से दूर, सभी साइट फ़ंक्शंस के लिए एक वेबसोकेट एपीआई में संक्रमण के बारे में सोच रहा हूं। इससे मेरे लिए साइट के सभी हिस्सों में वास्तविक समय सुविधाओं को एकीकृत करना आसान हो जाएगा। क्या इससे एप्लिकेशन या मोबाइल क्लाइंट बनाने में अधिक मुश्किल होगी?

मैंने पाया कि कुछ लोग पहले से ही इस तरह के सामान कर रहे हैं: सॉकेटस्ट्रीम

Comments

@Stegi लंबा मतदान एक कमबैक के रूप में काफी अच्छा काम करता है, इसके बारे में सुपर चिंतित नहीं है।

— हैरी

हैरी अब 7 साल बाद, यह आपके लिए कैसे काम करता है? आश्चर्य है, क्योंकि मैं उस दिशा में भी जाना चाहता हूं। @ हैरी

— दिमित्री

@DmitryKudryavtsev मैंने ऐसा नहीं किया। पारंपरिक विधि ने मेरे लिए अच्छा काम किया और बहुत कठिन नहीं थे।

— हैरी

Answer 1

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

मैं अपने ऐप को RESTful आर्किटेक्चर से लेकर RPC स्टाइल के और अधिक वेबस्केट्स पर ले जाने पर गंभीरता से विचार कर रहा हूं। यह एक "खिलौना ऐप" नहीं है, और मैं केवल रियलटाइम सुविधाओं के बारे में बात नहीं कर रहा हूं, इसलिए मेरे पास आरक्षण है। लेकिन मुझे इस मार्ग पर जाने में कई लाभ मिलते हैं और लगता है कि यह एक असाधारण समाधान हो सकता है।

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

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

इस प्रकार के समाधान की खोज में आपकी प्रगति के बाद मेरी दिलचस्पी होगी। यदि आपके पास कोई गितुब प्रयोग हैं, तो कृपया मुझे उन पर इंगित करें। मेरे पास अभी तक नहीं है, लेकिन जल्द ही उम्मीद है।

नीचे दी गई लिंक की एक सूची है जिसे मैंने पढ़ा है। मैं यह नहीं कह सकता कि वे सभी सार्थक हैं, क्योंकि मैंने उनमें से बहुतों को स्किम किया है। लेकिन उम्मीद है कि कुछ मदद करेंगे।

---

एक्सप्रेस के साथ सॉकेट.आईओ का उपयोग करने पर महान ट्यूटोरियल। यह socket.io के लिए एक्सप्रेस सत्रों को उजागर करता है और चर्चा करता है कि प्रत्येक प्रमाणित उपयोगकर्ता के लिए अलग कमरे कैसे हैं।

• http://www.danielbaulig.de/socket-ioexpress/

नोड.जेएस / सॉकेट.आईओ / बैकबोन.जेएस / एक्सप्रेस / कनेक्ट / जेड / रेडिस ऑन ऑथेंटिकेशन, जॉयंट होस्टिंग, आदि पर ट्यूटोरियल:

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Backbone.js के साथ पुशर का उपयोग करने पर ट्यूटोरियल (रेल का उपयोग करके):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

क्लाइंट पर backbone.js और सर्वर पर नोड, एक्सप्रेस, सॉकेट.io, dnode के साथ एप्लिकेशन बनाएँ।

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

DNode के साथ रीढ़ की हड्डी का उपयोग करना:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

Comments

मैंने सिर्फ एक संबंधित प्रश्न का उत्तर दिया और कुछ और विचार शामिल किए: stackoverflow.com/questions/4848642/…

— टॉरेन

"मेरे पास अभी भी एक लंबा रास्ता है इससे पहले कि मैं निश्चित रूप से कह सकता हूं कि यह एक अच्छा समाधान है" - बस जिज्ञासा, क्या यह वास्तव में एक अच्छा समाधान था? : D

— inf3rno

कृपया @Tauren का जवाब दें। मुझे बहुत दिलचस्पी है कि अब आपको क्या कहना है।

— No_name

@ तोरन मैं भी उत्सुक हूँ कि यह कैसे काम किया?

— कुर्रेन

Answer 2

HTTP REST और WebSockets बहुत अलग हैं। HTTP, स्टेटलेस है , इसलिए वेब सर्वर को कुछ भी जानने की आवश्यकता नहीं है, और आप वेब ब्राउज़र और प्रॉक्सी में कैशिंग प्राप्त करते हैं। यदि आप WebSockets का उपयोग करते हैं, तो आपका सर्वर स्टेटस हो रहा है और आपको सर्वर पर क्लाइंट से कनेक्शन की आवश्यकता है।

अनुरोध-उत्तर संचार बनाम पुश

यदि आपको सर्वर से क्लाइंट तक PUSH डेटा की आवश्यकता है, तो केवल WebSockets का उपयोग करें , यह संचार पैटर्न HTTP (केवल वर्कअराउंड द्वारा) में शामिल नहीं है। PUSH मददगार है अगर अन्य क्लाइंट्स द्वारा बनाई गई घटनाओं को अन्य कनेक्टेड क्लाइंट्स के लिए उपलब्ध होना चाहिए जैसे कि गेम्स में जहां यूजर्स को दूसरे क्लाइंट्स के व्यवहार पर कार्रवाई करनी चाहिए। या अगर आपकी वेबसाइट किसी चीज की निगरानी कर रही है, जहां सर्वर क्लाइंट को हर समय शेयर बाजारों (लाइव) जैसे डेटा को धक्का देता है।

यदि आपको सर्वर से PUSH डेटा की आवश्यकता नहीं है, तो आमतौर पर एक HTTP HTTP REST सर्वर का उपयोग करना आसान होता है। HTTP एक सरल अनुरोध-उत्तर संचार पैटर्न का उपयोग करता है ।

Comments

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

— हैरी

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

— हैरी

यह केवल वेबसीट का उपयोग करने के लिए एक अधिसूचना / कमांड को अपने वेबप में पुश करने के लिए है (जैसे गेटअप या रिफ्रेशऑब्जेक्टवाइट्स के साथ Params)। इस आदेश का विश्लेषण आपके वेबैप (क्लाइंट) में किया जा सकता है और इसके बाद वेबस्कैट के माध्यम से डेटा को ट्रांसपोर्ट करने के बजाय विशिष्ट डेटा प्राप्त करने का अनुरोध किया जाता है।

— बीचवॉकर

वहाँ कारणों की एक पूरी बहुत कुछ कर रहे हैं आसान हो सकता है REST कॉल की तुलना में - न केवल धक्का के लिए। websocket.org/quantum.html

— BT

WebSockets अद्भुत हैं, और क्लाइंट डेटा को भेजने के लिए किसी भी समय, क्लाइंट संदेश के जवाब में न केवल सर्वर को मुक्त करता है। वेबसॉकेट एक संदेश-आधारित प्रोटोकॉल को लागू करता है ताकि ग्राहक किसी भी समय संदेश प्राप्त कर सकें, और यदि वे किसी विशेष संदेश की प्रतीक्षा कर रहे हैं, तो वे बाद में प्रसंस्करण के लिए अन्य संदेशों को कतारबद्ध कर सकते हैं, कतारबद्ध संदेशों को फिर से व्यवस्थित कर सकते हैं, ऐप राज्य के आधार पर धक्का दिए गए संदेशों को अनदेखा कर सकते हैं, आदि। ' एक और REST- आधारित एप्लिकेशन को फिर कभी नहीं लिखेंगे। फ्लैश को भी आसान बनाता है, ओपन-सोर्स एएस 3-आधारित वेबसॉकेट कार्यान्वयन और बाहरीइंटरफेस के माध्यम से ब्राउज़र में कमबैक। (addCallback / call) विधियों के माध्यम से।

— त्रिवेंको

Answer 3

मैं सभी साइट फ़ंक्शंस के लिए एक WebSocket एपीआई में संक्रमण के बारे में सोच रहा हूं

नहीं। आपको ऐसा नहीं करना चाहिए। यदि आप दोनों मॉडलों का समर्थन करते हैं तो कोई नुकसान नहीं है। REST का उपयोग एक तरह से संचार / सरल अनुरोधों और दो तरह से संचार के लिए WebSocket खासकर जब सर्वर वास्तविक समय अधिसूचना भेजना चाहते हैं।

WebSocket Restful HTTP की तुलना में अधिक कुशल प्रोटोकॉल है, लेकिन अभी भी नीचे क्षेत्रों में WebSocket पर Restful HTTP स्कोर है।

1. HTTP के लिए अच्छे से Create / Update / Delete संसाधनों को परिभाषित किया गया है। आपको इन ऑपरेशनों को निम्न स्तर पर वेबस्केट के लिए लागू करना होगा।

2. WebSocket कनेक्शन एक सर्वर पर लंबवत रूप से जहां HTTP कनेक्शन स्केल क्षैतिज रूप से होता है। WebSocket क्षैतिज स्केलिंग के लिए कुछ मालिकाना गैर-मानक समाधान हैं।

3. HTTP बहुत सारे अच्छे फीचर्स के साथ आता है जैसे कैशिंग, रूटिंग, मल्टीप्लेक्सिंग, गज़िंगिंग आदि। यदि आपने वेबसोकेट को चुना है तो इसे वेबसैट के ऊपर बनाया जाना चाहिए।

4. HTTP URL के लिए सर्च इंजन ऑप्टिमाइज़ेशन अच्छा काम करता है।

5. सभी प्रॉक्सी, डीएनएस, फायरवॉल अभी तक पूरी तरह से वेबस्केट ट्रैफिक से अवगत नहीं हैं। वे पोर्ट 80 की अनुमति देते हैं, लेकिन पहले उस पर स्नूपिंग द्वारा यातायात को प्रतिबंधित कर सकते हैं।

6. WebSocket के साथ सुरक्षा ऑल-या-कुछ भी नहीं है।

अधिक जानकारी के लिए इस लेख को देखें।

Comments

यह सबसे अच्छा जवाब है।

— मैट वीलर

विषय के लिए शीर्ष उत्तर

— सैनड्रिया

Answer 4

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

इसलिए आप अन्य लोगों की गलतियों से नहीं सीख सकते हैं और विकास धीमा होने वाला है। यह एक "कोशिश और परीक्षण" रणनीति भी नहीं है।

निश्चित रूप से आपके भी HTTP के सभी फ़ायदे कम होने वाले हैं (स्टेटलेस होना, और कैशिंग करना बड़े फायदे हैं)।

याद रखें कि वेब सामग्री परोसने के लिए डिज़ाइन किया गया टीसीपी के लिए HTTP एक अमूर्त है।

और यह मत भूलो कि एसईओ और खोज इंजन वेबस्कॉक नहीं करते हैं। तो आप SEO के बारे में भूल सकते हैं।

व्यक्तिगत रूप से मैं इसके खिलाफ सिफारिश करूंगा क्योंकि बहुत अधिक जोखिम है।

वेबसाइटों की सेवा के लिए WS का उपयोग न करें, वेब अनुप्रयोगों की सेवा के लिए इसका उपयोग करें

हालांकि अगर आपके पास कोई खिलौना है या निजी वेबसाइट है तो इसके लिए जाएं। कोशिश करो, अत्याधुनिक हो। किसी व्यवसाय या कंपनी के लिए आप ऐसा करने के जोखिम को उचित नहीं ठहरा सकते।

Answer 5

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

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

हमें वास्तव में कनेक्शन को विश्वसनीय बनाने के लिए कुछ समय शांत करना था। हमने कुछ सस्ते वेबसोकेट ट्यूटोरियल के साथ शुरुआत की, लेकिन पता चला कि कनेक्शन के टूटने पर हमारा कार्यान्वयन स्वचालित रूप से पुन: कनेक्ट करने में सक्षम नहीं था। जब हम सॉकेट-आईओ पर स्विच करते हैं तो यह सब सुधर जाता है। सॉकेट-आईओ एक चाहिए!

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

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

• क्योंकि कुछ ही समय बाद हमें पता चला कि अमेज़ॅन की क्लाउड सेवाएं (AWS) Restful अनुप्रयोगों के लिए कुछ बेहतरीन लोड-बैलेंसिंग / स्केलिंग टूल प्रदान करती हैं ।
• हमें अब यह आभास होता है कि हमें CRUD ऑपरेशन के हैंडशेक करने के लिए बहुत सारे कोड लिखने होंगे ।
• हाल ही में हमने पेपैल एकीकरण को लागू किया। हम इसे काम करने में कामयाब रहे। लेकिन फिर से, सभी ट्यूटोरियल इसे रेस्टफुल एपीआई के साथ कर रहे हैं । वेबस्केट्स के साथ उन्हें लागू करने के लिए हमें उनके उदाहरणों को फिर से लिखना / पुनर्विचार करना होगा। हम इसे हालांकि काफी तेजी से काम करने के लिए मिला है। लेकिन यह महसूस करता है कि हम प्रवाह के खिलाफ जा रहे हैं ।

यह सब कहने के बाद, हम अगले हफ्ते लाइव हो रहे हैं। हम समय पर वहां पहुंच गए, सब कुछ काम करता है। और यह तेज़ है, लेकिन क्या यह पैमाना होगा?

Comments

जैसा कि हम इस निर्णय को स्वयं करने की कोशिश कर रहे हैं, क्या यह सोचकर कि यह AWS के साथ अच्छा था?

— गाबे

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

— bvdb

Answer 6

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

काम का अलग होना इस तरह से है:

1. WebSockets सर्वर के साथ संवाद करने के लिए एक आवेदन की प्राथमिक विधि होगी जहां एक सत्र की आवश्यकता होती है। यह पुराने ब्राउज़र के लिए आवश्यक कई हैक को समाप्त करता है (पुराने ब्राउज़र के लिए समस्या समर्थन है जो इसे समाप्त कर देगा)

2. RESTful API का उपयोग GET कॉल के लिए किया जाता है जो सत्र उन्मुख नहीं हैं (अर्थात आवश्यक प्रमाणीकरण नहीं) जो ब्राउज़र कैशिंग से लाभान्वित होते हैं। इसका एक अच्छा उदाहरण एक वेब एप्लिकेशन द्वारा उपयोग किए जाने वाले ड्रॉप डाउन के लिए संदर्भ डेटा होगा। तथापि। थोड़ा अधिक बार से बदल सकते हैं ...

3. HTML और जावास्क्रिप्ट। इनमें webapp का UI शामिल है। ये आमतौर पर CDN पर रखे जाने से लाभान्वित होंगे।

4. WSDL का उपयोग करने वाली वेब सेवाएँ अभी भी एंटरप्राइज़ स्तर और क्रॉस-एंटरप्राइज़ संचार का सबसे अच्छा तरीका हैं क्योंकि यह संदेश और डेटा पासिंग के लिए एक अच्छी तरह से परिभाषित मानक प्रदान करता है। मुख्य रूप से आप इसे अपने वेब सर्विस हैंडलर पर प्रॉक्सी करने के लिए डाटापॉवर डिवाइस पर लोड करेंगे।

यह सब HTTP प्रोटोकॉल पर होता है जो पहले से ही एसएसएल के माध्यम से सुरक्षित सॉकेट का उपयोग करता है।

मोबाइल एप्लिकेशन के लिए, हालांकि, वेबसोकेट वापस डिस्कनेक्ट किए गए सत्र (वेब कनेक्शन को वेब कनेक्शन से कैसे कनेक्ट करें) को फिर से कनेक्ट नहीं कर सकता है और प्रबंधित नहीं कर सकता है। इसलिए मोबाइल ऐप्स के लिए , मैं अभी भी REST API और पोलिंग की सलाह दूंगा ।

वेबस्टॉप्स बनाम REST का उपयोग करते समय देखने के लिए एक और बात स्केलेबिलिटी है । WebSocket सत्र अभी भी सर्वर द्वारा प्रबंधित किए जाते हैं। सही तरीके से किए जाने पर RESTful API स्टैटेबल होता है (जिसका अर्थ है कि कोई सर्वर स्थिति नहीं है जिसे प्रबंधित करने की आवश्यकता है), इस प्रकार स्केलेबिलिटी क्षैतिज रूप से (जो सस्ती है) लंबवत से बढ़ सकती है ।

Answer 7

क्या मुझे सर्वर से अपडेट चाहिए?

• हाँ: सॉकेट
• कोई आराम नहीं

Socket.io के लिए निम्न हैं:

• स्केलेबिलिटी: वेबस्केट को वेब कनेक्शन के लिए खुले कनेक्शन और बहुत अलग ऑप्स सेटअप की आवश्यकता होती है।
• सीख: मेरे पास अपने सीखने के लिए असीमित समय नहीं है। चीजें पूरी करनी हैं!

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

Answer 8

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

REST संसाधन आधारित वास्तुकला है जिसे अच्छी तरह समझा जाता है और यह अन्य आर्किटेक्चर पर अपने फायदे प्रदान करता है। वेबसॉकेट वास्तविक समय में डेटा की स्ट्रीम / फीड के लिए अधिक लाइक करता है जिसके लिए आपको संसाधनों और फीड के बीच अंतर करने या अंतर करने के लिए किसी प्रकार का सर्वर आधारित लॉजिक बनाना होगा (यदि आप REST का उपयोग नहीं करना चाहते हैं)।

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

Answer 9

मैं इस ब्लॉग पोस्ट को इंगित करना चाहता हूं जो मेरे ऊपर है, इस सवाल का सबसे अच्छा जवाब।

संक्षेप में, हाँ

इस तरह के एपीआई के लिए पोस्ट में सभी सर्वोत्तम अभ्यास हैं।

Answer 10

यह एक अच्छा विचार नहीं है। मानक को अभी भी अंतिम रूप नहीं दिया गया है, समर्थन ब्राउज़रों में भिन्न होता है, आदि। यदि आप ऐसा करना चाहते हैं, तो अब आपको फ़्लैश या लॉन्ग पोलिंग आदि के लिए कमबैक की आवश्यकता होगी, भविष्य में यह अभी भी संभव नहीं होगा। बहुत सारे अर्थ, चूंकि सर्वर को हर एक उपयोगकर्ता के लिए खुला कनेक्शन छोड़ने का समर्थन करना है। अधिकांश वेब सर्वरों को जल्दी से अनुरोधों का जवाब देने और जल्दी से जल्दी उन्हें बंद करने के बजाय उत्कृष्टता के लिए डिज़ाइन किया गया है। हेक यहां तक ​​कि आपके ऑपरेटिंग सिस्टम को उच्च संख्या में युगपत कनेक्शन (प्रत्येक कनेक्शन और अधिक अल्पकालिक पोर्ट और मेमोरी का उपयोग करके) से निपटने के लिए ट्यून करना होगा। जितना हो सके उतना साइट के लिए REST का उपयोग करने के लिए चिपके रहें।

Comments

हाँ, अधिकांश webserves HTTP पर एक्सेल हैं। लेकिन नोड.जेएस एक वेब सर्वर नहीं है, यह एक io पुस्तकालय है। यह ठीक टीसीपी कर सकता है। सवाल मूल रूप से कह रहा है कि हम HTTP के बजाय टीसीपी का उपयोग करने के लिए वेबसाइट डिजाइन कर सकते हैं।

— रायनोस

वही प्रतिबंध लागू होते हैं, आप अभी भी पंचांग बंदरगाहों / मेमोरी से बाहर चलेंगे, यह अभी भी सीमित करेगा कि आप कितने लोगों को एक साथ सेवा कर सकते हैं, और सिस्टम पर अनावश्यक बोझ डाल सकते हैं।

— ज़ेके

हाँ, एक सीमा है लेकिन मुझे नहीं लगता कि यह बहुत बड़ी बात है यदि आप प्रति कनेक्शन एक नया धागा नहीं बनाते हैं।

— रायनोस

मेरे पास पहले से ही प्रत्येक उपयोगकर्ता के लिए एक सॉकेट है। वैश्विक चैट + न्यूज़फ़ीड।

— हैरी

मुझे लगता है कि 2011 में यह एक महान अन्वेषक था। - तो, ​​मैं देख रहा हूं कि आप कहां से आ रहे हैं। लेकिन 2019 में, वेबसोकेट परिपक्व हो गए हैं।

— bvdb