हमें Restful Web Services की आवश्यकता क्यों है?

Question

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

मैंने विकिपीडिया में कुछ जानकारी पढ़ी है और मैंने Sun Developer Network पर REST के बारे में एक लेख भी पढ़ा है और मैं देखता हूं कि यह आसान तकनीक नहीं है, Restful apps बनाने के लिए विशेष रूपरेखाएँ हैं, और यह अक्सर SOAP वेब सेवाओं और प्रोग्रामर को यह समझना चाहिए कि एसओएपी का उपयोग कब करना है और कब आरईएसटी अच्छा तरीका हो सकता है।

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

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

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

UPD : Unfortunatelly मैं कोई ठोस तर्क नहीं देख सकता, जो पहली टिप्पणी में मेरे दिमाग को उड़ा सकता है। मुझे लगता है कि REST बहुत बढ़िया तकनीक है!

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

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

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

Comments

यह एक भयानक तकनीक नहीं है - यह एक अलग तकनीक है। यदि आप चाहते हैं कि कोई आपको मना ले तो यह बहुत बढ़िया है और हर बार इसका इस्तेमाल किया जाना चाहिए, एक सलाहकार की कोशिश करें।

— क्विलब्रेकर

Answer 1

यदि किसी वितरित एप्लिकेशन में क्लाइंट और सर्वर घटकों के बीच युग्मन को कम करना आपके लिए बहुत महत्वपूर्ण है तो REST का उपयोग किया जाना चाहिए ।

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

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

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

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

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

अपडेट करें

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

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

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

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

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

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

ये काम में एक अन्य वास्तुकला के उदाहरण हैं।

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

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

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

Comments

@ डेरेल: दुनिया में SOAP पर युग्मन को कैसे कम करता है? या, SOAP REST पर युग्मन कैसे बढ़ाता है? क्या आप इस तथ्य का उल्लेख कर रहे हैं कि एक SOAP क्लाइंट को वास्तव में SOAP को समझने की आवश्यकता है, लेकिन एक REST क्लाइंट को केवल मीडिया प्रकारों को समझने की आवश्यकता है?

— जॉन साउन्डर्स

@ जॉन आमतौर पर जिस तरह से SOAP का उपयोग किया जाता है, उसके कारण क्लाइंट को प्रत्येक सर्वर साइड एंडपॉइंट के ज्ञान, प्रत्येक पैरामीटर डेटा प्रकार और प्रत्येक रिटर्न प्रकार में "संकलित" की आवश्यकता होती है। ग्राहक और सर्वर के बीच डेटा पारित करने के लिए मानकीकृत प्रकारों का उपयोग करने के लिए SOAP दुनिया में कोई मार्गदर्शन नहीं है। इसका मतलब है कि हर नई सेवा जो एक ग्राहक डेवलपर उपयोग करने के लिए जाती है, उसके पास विशिष्ट प्रकार के प्रकार, समापन बिंदु और इंटरैक्शन प्रोटोकॉल होते हैं। वह कपलिंग है।

— डारेल मिलर

@ जॉन्स्ट ने HTTP क्रियाओं के शब्दार्थों को इंटरैक्शन प्रोटोकॉल को मानकीकृत करने का प्रयास किया, आईएएनए पंजीकृत प्रकारों के डेटा प्रारूप और सभी समापन बिंदु गतिशील रूप से खोजे जाने योग्य होने चाहिए। इसका मतलब है कि क्लाइंट / सर्वर युग्मन को मीडिया प्रकार की परिभाषा के लिए स्थानीय बनाया गया है। जैसे ही रिच ने कहा, "आपकी सेवा युग्मन के दायरे को केवल एक चीज़ - मीडिया प्रकारों के लिए बताती है।"

— डारेल मिलर

@ डारेल: यह पारंपरिक अर्थों में युग्मन नहीं है। क्लाइंट को मेटाडेटा (WSDL) के लिए "युग्मित" माना जा सकता है, लेकिन सेवा के लिए नहीं। एक ऐसी सेवा पर विचार करें जो "कर्मचारी" लौटाती है: {int id; string firstName, lastName, streetAddress1, streetAddress2, शहर, राज्य; int zip;} आप या तो यह सुझाव दे रहे हैं कि हम "कर्मचारी" को आईएएनए के साथ पंजीकृत करते हैं, या हम सिर्फ "कर्मचारी" को नाम / मूल्य जोड़े के एक सहयोगी सरणी मानते हैं।

— जॉन सॉन्डर्स

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

— डारेल मिलर

Answer 2

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

शोध प्रबंध के शीर्ष पर एक उद्धरण है:

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

- क्रिस्टोफर अलेक्जेंडर, द टाइमलेस वे ऑफ़ बिल्डिंग (1979)

और वह वास्तव में वहाँ योग करता है। REST कई मायनों में अधिक सुरुचिपूर्ण है।

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

Comments

SOAP को 1998 में वापस परिभाषित किया गया था। तब कितने HTTP "कन्वेंशन" कन्वेंशन थे?

— जॉन साउन्डर्स

इस w3.org/Protocols/HTTP/1.0/spec.html HTTP के अनुसार 1990 से उपयोग में है। तो क्या? हम सभी जानते हैं कि SOAP http का उपयोग करने का एकमात्र कारण था क्योंकि पोर्ट 80 फ़ायरवॉल पर खुले होने की सबसे अधिक संभावना थी। Microsoft फिर DCOM गलती नहीं करने वाला था।

— डारेल मिलर

" REST HTTP के साथ बनाया गया है बजाय इसके ऊपर से " +1। यह पूरा थ्रेड मेरे लिए वास्तव में SOAP और इसके विपरीत में REST के उपयोग की वैधता को समझने में मददगार है।

— 1922 में क्रिस 22

Answer 3

से यहाँ :

अन्य लाभ:

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

यह भी जांच इस बाहर:

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

Comments

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

— एमिल इवानोव

@ ईमिल - ध्यान रखें कि एसएसएल हमेशा उपलब्ध नहीं होता है। कुछ लोग संदेश आधारित सुरक्षा चाहते हैं न कि परिवहन स्तर आधारित सुरक्षा। और जहाँ तक एक POST ... का उपयोग कर रहा है ... POST REST अनुरोधों को संसाधित करने के लिए उपयोग की जाने वाली क्रियाओं में से एक है। अपनी आवश्यकताओं को पूरा करने के लिए आप इसका उपयोग हमेशा नहीं कर सकते।

— जस्टिन नीसनर

एक बड़ा CON: SOAP सेवाओं के लिए WSDL की तरह कोई मानकीकृत "विवरण" भाषा नहीं है - प्रत्येक REST सेवा का दस्तावेजीकरण हो सकता है या नहीं भी हो सकता है, और प्रलेखन गुणवत्ता सेवा की पेशकश से बहुत भिन्न है .....

— marc_s

@Marc_s यदि REST ठीक से किया जाता है तो WSDL की तरह "विवरण भाषा" की कोई आवश्यकता नहीं है। उपयोग किए जाने वाले मीडिया-प्रकारों को प्रलेखित किए जाने की आवश्यकता होती है, लेकिन ऐसे दस्तावेज़ मौजूद नहीं होने चाहिए जो जोड़े मीडिया-प्रकारों के लिए इंगित करते हैं।

— डारेल मिलर

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

— जॉन सॉन्डर्स

Answer 4

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

बस आपको अंदर खींचने के लिए

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

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

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

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

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

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

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

Comments

तो विधि के बजाय ऑब्जेक्ट होने का क्या लाभ है?

— सौम्या राउत

Answer 5

यहाँ कुछ विचार हैं:

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

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

Comments

@ जॉन अगर मैं VS फायर करता हूं और WCF प्रोजेक्ट बनाता हूं और [ServiceContract] विशेषता के साथ एक इंटरफ़ेस बनाता हूं, तो मुझे अपनी पसंद के किसी भी तरीके के कॉल को जोड़ सकते हैं। CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvucation (), CancelOrder () उन तरीकों से, क्या आप मुझे बता सकते हैं कि मुझे ऑर्डर करने के लिए किस क्रम का उपयोग करना चाहिए? क्या आप मुझे बता सकते हैं कि मुझे रद्द करने की अनुमति कब दी गई है ()? क्या मुझे आदेश की पुष्टि करने से पहले उपलब्ध होने की जांच करनी चाहिए? क्या मुझे उपलब्धता जाँचने से पहले आदेश को सत्यापित करना चाहिए? पेरोल करने के लिए यह इंटरसेक्स एक के साथ संगत होने की संभावना नहीं है।

— डारेल मिलर

@ विवाद: मैं यह नहीं देखता कि REST इसे कैसे हल करता है। क्या और के MakeOrderलिए URL देता है ? क्या ग्राहक को पहले से ही पता नहीं है कि सेवा को कैसे कॉल करना है, बल्कि डेटा-संचालित करने की आवश्यकता है? ConfirmOrderCancelOrder

— जॉन सॉन्डर्स

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

— डारेल मिलर

@Darrel: मुझे लगता है कि मैंने कभी कोई व्यावसायिक-महत्वपूर्ण सेवा नहीं देखी है, जहां मैं यह निर्धारित करना चाहता हूं कि मुझे पिछली कॉल से किस URL के आधार पर अगला कॉल करना है।

— जॉन Saunders

@ जॉनसनर्स: ऐसा इसलिए है क्योंकि एक रीस्ट कॉल विधि कॉल के बारे में नहीं है, लेकिन राज्य संक्रमण (राज्य मशीन लगता है)। किसी भी दिए गए राज्य में, एक RESTful सर्वर वैध स्टेट ट्रांज़िशन निर्दिष्ट करेगा और उपयोगकर्ता या उपयोगकर्ता एजेंट उन बदलावों को चुनता है जिन्हें वह अनुसरण करना चाहता है।

— रेयान

Answer 6

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

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

Comments

सार्वजनिक रूप से दिखाई देने वाला सबसे अच्छा उदाहरण सन क्लाउड एपीआई है। यहाँ एक walkthrough kenai.com/projects/suncloudapis/pages/… SOAP के साथ अपने अनुभव को अर्हता प्राप्त करने के लिए बस है। मैंने पैटर्न और व्यवहार समूह से Microsoft की वेब सेवा सॉफ़्टवेयर फ़ैक्टरी का उपयोग करके ASMX वेब सेवाओं का निर्माण, और अभी भी समर्थन किया है। मैंने उसी सॉफ़्टवेयर कारखाने के बाद के रिलीज़ का उपयोग करके WCF आधारित सेवाओं का निर्माण किया है। मैंने WCF के System.ServiceModel का उपयोग भी किया है। जब से पहली बार मई 2007 में Biztalk Services SDK के साथ रिलीज़ किया गया था।

— डेरेल मिलर

जॉन- बाकी एपीआई का एक उदाहरण अमेज़ॅन एक है। उनके पास @SOAP और REST API दोनों हैं। यह आपके लिए उपयोगी हो सकता है- docs.amazonwebservices.com/AmazonS3/latest/…

— :

Answer 7

पहले से दिए गए उत्तरों पर थोड़ा सा प्रॉसिक स्पिन जोड़ने के लिए, क्योंकि हम REST सेवाओं का उपयोग करते हैं, जहां मैं यह हूं कि यदि आप जानते हैं कि आप किसी बिजनेस पार्टनर को एक URL सौंप सकते हैं और उन्हें पता चलेगा कि बदले में, XML की अच्छी तरह से रखी गई स्लैब कोई फर्क नहीं पड़ता कि वे काम कर रहे हैं। नेट xx, PHP, पायथन, जावा, रूबी या भगवान-जानता है कि यह गंभीर सिरदर्द है।

इसका मतलब यह भी है कि गैर-तकनीकी छोर पर हमारी बिक्री लोगों को हमारे बहुमुखी एपीआई के बारे में पूरी तरह से muppets की तरह डर के बिना लोगों के बारे में अपनी बड़ाई कर सकती है।

तकनीकी लाभों के अलावा बहुत कुछ ऐसा है जो किसी गैर-तकनीकी विशेषज्ञ के लिए समझाने, प्रदर्शित करने और आत्मविश्वास महसूस करने के लिए आसान है, अच्छी बात है। SOAP, हालाँकि तकनीकियों के लिए जितना अच्छा है, गैर-तकनीकी लोगों द्वारा उतना कम स्वीकार्य है और इसलिए "बेचना" उतना आसान नहीं है।

मैं ध्यान देता हूं कि गैर-तकनीकी चीजें अपने सिर को गोल करने के लिए ला सकती हैं। इसलिए मुझे संदेह है कि REST एक तकनीक के रूप में उत्तरदायी है, जो कि SOAP के रूप में फैशन की सनक के लिए अतिसंवेदनशील है।

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

Answer 8

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

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

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

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

Comments

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

— 1822 बजे क्रिस 22