web services - हमें रीस्टफुल वेब सेवाओं की आवश्यकता क्यों है?




web-services rest (6)

मैं रीस्टफुल वेब सेवाओं को सीखने जा रहा हूं (यह कहना बेहतर है कि मुझे ऐसा करना होगा क्योंकि यह सीएस मास्टर डिग्री प्रोग्राम का हिस्सा है)।

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

मुझे याद है कि कई साल पहले एसओएपी बहुत लोकप्रिय था (फैशनेबल?) और आइटम 'एसओएपी' हर अच्छे सीवी में मौजूद होना था। लेकिन व्यवहार में यह बहुत ही कम इस्तेमाल किया गया था और बहुत ही सरल उद्देश्यों को प्राप्त करने के लिए।

ऐसा लगता है कि आरईएसटी एक और 'फैशन का अंतिम शब्द' है (या मैं पूरी तरह गलत हो सकता हूं क्योंकि मैंने कभी अभ्यास में आरईएसटी नहीं देखा है)।

क्या आप मुझे कुछ उदाहरण दे सकते हैं आरईएसटी का इस्तेमाल किया जाना चाहिए और हम आरईएसटी के बिना ऐसा क्यों नहीं कर सकते (या हमें आरईएसटी के बिना ऐसा करने के लिए और अधिक समय क्यों खर्च करना चाहिए)?

यूपीडी : दुर्भाग्य से मैं कोई ठोस तर्क नहीं देख सकता जो मेरी दिमाग को पहली टिप्पणियों में उड़ा सकता है। मुझे लगता है कि आरईएसटी भयानक तकनीक है!

मैं इस तरह के जवाब देखना चाहता हूं:

मैं एक और जटिल हैलोवर्ल्ड एप्लिकेशन विकसित कर रहा था और हमें बहुत सारे / छोटे डेटा को स्थानांतरित करने की आवश्यकता है और मैंने अपने कार्यकर्ता को आरईएसटी समाधान का प्रस्ताव दिया है:

- ओह लानत! जॉनी, हमें निश्चित रूप से इस ऐप को लागू करने के लिए आरईएसटी का उपयोग करना चाहिए!
- हाँ, बिली, हम आरईएसटी का उपयोग कर सकते हैं, लेकिन हम बेहतर एसओएपी का उपयोग करेंगे। मेरा विश्वास करो 'क्योंकि मुझे हैलोवर्ल्ड अनुप्रयोगों के विकास के बारे में कुछ पता है।
- लेकिन एसओएपी पिछली शताब्दी से पुरानी तकनीक है और हम बेहतर उपयोग कर सकते हैं।
- बिली, क्या आप आरईएसटी के साथ प्रयोग करने के लिए 3 दिन बिताएंगे? हम इसे 2 घंटे में SOAP के साथ कर सकते हैं ..
- हाँ, मुझे यकीन है कि हम एक ही सुरक्षा / प्रदर्शन / स्केलेबिलिटी / एसओएपी के साथ जो कुछ भी हासिल करने के लिए और भी अधिक समय बिताएंगे। मुझे यकीन है कि हैलोवर्ल्ड अनुप्रयोगों को केवल आरईएसटी के साथ ही विकसित किया जाना चाहिए।


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

मुझे यह भी मानना ​​है कि कई "समर्थक" अंक ऐसी चीजों की तरह लगते हैं जो वास्तव में सच हो सकते हैं - लेकिन मैंने कभी ऐसा उदाहरण नहीं देखा है जो उनके मूल्य को दर्शाता है। विशेष रूप से, अगर कोई एक आरईएसटी वेब सेवा के अच्छे उदाहरण के लिए एक लिंक वाला कोई टिप्पणी पोस्ट करेगा तो मैं इसकी बहुत सराहना करता हूं। यह एक ऐसा होना चाहिए जो संसाधन के कई स्तरों का उपयोग करता है, संभवतः पदानुक्रम में, और जो मीडिया प्रकारों का सही ढंग से उपयोग करता है। शायद अगर मैं एक अच्छा उदाहरण देखता हूं, तो मैं समझूंगा, इस मामले में, मैं यहां वापस आऊंगा और इसे स्वीकार करूंगा।


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

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

आरईएसटी आरपीसी (रिमोट प्रोसेसर कॉल) और वेब सर्विसेज (एसओएपी, डब्ल्यूएसडीएल, एट अल।) जैसे तंत्रों के लिए हल्का विकल्प है। बाद में, हम देखेंगे कि आरईएसटी कितना आसान है।

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


मैं सुरक्षित रूप से कह सकता हूं कि मैंने इसे शुरुआती के रूप में समझने में काफी समय बिताया है लेकिन आरईएसटी से शुरू करने के लिए यह सबसे अच्छा लिंक है! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

बस आपको खींचने के लिए,

सोचें कि "पारंपरिक वेब सेवा" क्या है। यह खुलासा "विधियों" के साथ एक इंटरफ़ेस है। ग्राहक विधियों के नाम, इनपुट और आउटपुट को जानते हैं और इसलिए उन्हें कॉल कर सकते हैं।

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

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

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

आपको सोचना चाहिए - ठीक है, डलास के मौसम में जाने के लिए, ग्राहक के रूप में, यह आपकी मदद कैसे करता है? हम कुछ क्षणों में उस पर पहुंच जाएंगे।

यदि आप वेब सेवा से प्राप्त होते हैं तो "ऑब्जेक्ट्स का सेट" होता है, जाहिर है कि आपको "उन पर कार्य करने" के लिए एक तरीका चाहिए। ऑब्जेक्ट्स के पास आपके लिए कॉल करने के लिए कोई तरीका नहीं है, इसलिए आपको उन कार्रवाइयों के एक सेट की आवश्यकता है जिन्हें आप इन ऑब्जेक्ट्स पर लागू कर सकते हैं। दूसरे शब्दों में, आपको "संज्ञा के लिए एक क्रिया लागू करने" की आवश्यकता है। यदि आप किसी ऑब्जेक्ट को देखते हैं, तो कहें, एक सेब, जो "संज्ञा" है, आप इसे "क्रिया" जैसे खाने के लिए लागू कर सकते हैं। लेकिन सभी क्रियाओं को सभी संज्ञाओं पर लागू नहीं किया जा सकता है। जैसे, आप एक कार चला सकते हैं, लेकिन एक टेलीविजन ड्राइव नहीं कर सकते हैं।

इस प्रकार, यदि कोई वेब सेवा केवल ऑब्जेक्ट्स को उजागर करती है, और आपसे पूछा जाता है - ठीक है, अब हम कुछ मानक क्रियाएं या क्रियाएं तैयार करें जो "सभी क्लाइंट वे देखे गए सभी ऑब्जेक्ट्स पर लागू हो सकते हैं" ...


यहां कुछ विचार दिए गए हैं:

  • आरईएसटी एक समान इंटरफ़ेस का उपयोग करने के लिए आपकी सेवा को बाधित करता है। आपको अपनी सेवा के सभी संभावित तरीकों के बारे में दिन-समय पर (या बहस) बर्बाद करने की ज़रूरत नहीं है - आपको अपने सिस्टम में संसाधनों की पहचान करने का काम करने का अधिकार मिलता है। अपने आप में एक बड़ी नौकरी बन जाती है, लेकिन सौभाग्य से समस्याएं बहुत बेहतर परिभाषित होती हैं।
  • संसाधनों, उनके संगठनों और उनके प्रतिनिधित्वों के साथ, आपकी सेवा को लागू करने में वास्तव में बहुत कम करना है क्योंकि आपके लिए कई निर्णय किए गए हैं।
  • आपका सिस्टम अन्य रीस्टफुल सिस्टम की तरह दिखता है; टीम के साथी, भागीदारों और ग्राहकों के लिए सीखने के घटता कम हो जाएंगे।
  • अन्य डेवलपर्स के साथ डिजाइन समस्याओं पर चर्चा करने के लिए आपके पास एक सामान्य शब्दावली होगी, और यहां तक ​​कि कम तकनीकी रूप से दिमागी (जैसे ग्राहकों) के साथ भी।
  • जैसा कि डैरल कहते हैं, क्योंकि आप एक hypertext-driven डिज़ाइन का उपयोग कर रहे हैं, इसलिए आपकी सेवा युग्मन के दायरे को केवल एक चीज - मीडिया प्रकारों के बारे में बताती है। यह आपको डेवलपर के रूप में मदद करता है क्योंकि आपके सिस्टम में बदलाव संपर्क के संकीर्ण बैंड के भीतर निहित हैं। यह आपके ग्राहकों को आपके कम परिवर्तनों में उनके कोड को तोड़ने में सहायता करता है।
  • आरईएसटी को लागू करने में आपके पास होने वाली लगभग हर समस्या को एक नया संसाधन उजागर करके या अपने संसाधन मॉडल को फिर से सोचकर हल किया जा सकता है। यह फोकस है, आईएमओ, एक बड़ी उत्पादकता वृद्धि।

निचली पंक्ति, आरईएसटी आपकी टीम के वर्कफ़्लो से सबसे अधिक समय लेने वाली और विवादास्पद डिज़ाइन और कार्यान्वयन निर्णयों को हटा देती है। यह आपकी सेवा को डिजाइन करने के लिए इसे लागू करने से आपका ध्यान बदल देता है। और यह HTTP प्रोटोकॉल पर gobbledygook piling बिना ऐसा करता है।


वितरित अनुप्रयोग में क्लाइंट और सर्वर घटकों के बीच युग्मन को कम करने के लिए आरईएसटी का उपयोग किया जाना चाहिए।

यह मामला हो सकता है यदि आपका सर्वर कई अलग-अलग ग्राहकों द्वारा उपयोग किया जा रहा है जिन पर आपका नियंत्रण नहीं है। यह भी मामला हो सकता है यदि आप क्लाइंट सॉफ़्टवेयर को अद्यतन करने के बिना नियमित रूप से सर्वर को अद्यतन करने में सक्षम होना चाहते हैं।

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

समान HTTP इंटरफ़ेस में समृद्ध सर्वर व्यवहार को अपनाना भ्रमित हो सकता है और समय-समय पर अपेक्षाकृत सरल आरपीसी दृष्टिकोण की तुलना में पैडेंटिक दिखाई देता है।

कठिनाइयों के बावजूद, लाभ यह है कि आपके पास ऐसी सेवा है जो क्लाइंट डेवलपर को HTTP प्रोटोकॉल के निरंतर उपयोग के कारण आसानी से समझने में सक्षम होना चाहिए। हाइपरमीडिया के कारण सेवा आसानी से खोजी जा सकती है और क्लाइंट सर्वर पर बदलावों के लिए बेहद लचीला होना चाहिए।

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

अद्यतन करें

ऐसा लगता है कि आरईएसटी एक और 'फैशन का अंतिम शब्द' है (या मैं पूरी तरह गलत हो सकता हूं क्योंकि मैंने कभी अभ्यास में आरईएसटी नहीं देखा है)।

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

आप कहते हैं कि आपने अभ्यास में आरईएसटी कभी नहीं देखा है, लेकिन यदि आप कभी भी वेब ब्राउज़र का उपयोग करते हैं तो यह संभव नहीं हो सकता है। वेब ब्राउज़र एक आरईएसटी ग्राहक है।

  • जब कोई वेब साइट पर कुछ एचटीएमएल बदलता है तो आपको ब्राउज़र अपडेट करने की आवश्यकता क्यों नहीं है?
  • मैं वेब साइट पर पृष्ठों का एक पूरा नया सेट क्यों जोड़ सकता हूं और "क्लाइंट" अभी भी अपडेट के बिना उन नए पृष्ठों तक पहुंच सकता है?
  • मुझे यह जानने के लिए वेब ब्राउज़र में "सेवा-वर्णन-भाषा" प्रदान करने की आवश्यकता क्यों नहीं है जब यह http://example.org/images/cat जाता है कि रिटर्न प्रकार एक जेपीईजी छवि होगी और जब आप जाएं http://example.org/description/cat पर वापसी प्रकार टेक्स्ट / एचटीएमएल होगा?
  • मैं उन वेब साइटों का दौरा करने के लिए वेब ब्राउज़र का उपयोग क्यों कर सकता हूं जो ब्राउज़र जारी होने पर मौजूद नहीं थे? क्लाइंट इन साइटों के बारे में कैसे जान सकता है?

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

प्रमाणीकरण के लिए विभिन्न ओपनआईडी सेवाओं का उपयोग करता है, अवतार छवियों के लिए gravatar.com, विश्लेषणात्मक जानकारी के लिए google-analytics और Quantserve। इस प्रकार की बहु-कंपनी एकीकरण एसओएपी दुनिया का केवल सपना है । सबसे अच्छे उदाहरणों में से एक यह तथ्य है कि UI को चलाने के लिए उपयोग की जाने वाली jQuery लाइब्रेरी को Google के सामग्री वितरण नेटवर्क से पुनर्प्राप्त किया जाता है। तथ्य यह है कि एसओ क्लाइंट को निर्देशित करने के लिए किसी तीसरे पक्ष की साइट से कोड डाउनलोड करने के लिए क्लाइंट (यानी आपका वेब ब्राउज़र) निर्देशित कर सकता है, वेब क्लाइंट और सर्वर के बीच कम युग्मन के लिए प्रमाण पत्र है।

ये काम पर एक आरईएसटी वास्तुकला के उदाहरण हैं।

अब कुछ वेब साइट्स / एप्लिकेशन आरईएसटी के नियम तोड़ते हैं और फिर ब्राउजर अपेक्षित काम नहीं करता है।

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

आरईएसटी हर जगह है। यह वेब का हिस्सा है जो इसे अच्छी तरह से काम करता है। यदि आप वितरित अनुप्रयोगों को बनाना चाहते हैं जो वेब की तरह स्केल कर सकते हैं, वेब की तरह बदलने के लिए लचीला रहें और वेब के रूप में पुन: उपयोग को बढ़ावा देने के लिए प्रोत्साहित करें, फिर वेब ब्राउज़र बनाने के दौरान किए गए नियमों का पालन करें।


here :

पिछले फायदे:

  • लाइटवेट - बहुत अधिक एक्सएमएल मार्कअप नहीं
  • मानव पठनीय परिणाम
  • निर्माण करने में आसान - कोई टूलकिट आवश्यक नहीं है

यह भी देखें:

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







architecture