REST क्या है? थोड़ा उलझन में [बंद]


155

मैं इस धारणा के तहत था कि REST एक वेब सेवा थी, लेकिन ऐसा लगता है कि मैं यह सोचने में गलत हूं - तो, ​​REST क्या है?

मैंने विकिपीडिया के माध्यम से पढ़ा है, लेकिन अभी भी इसके चारों ओर मेरे सिर को नहीं लपेट सकता। क्यों कई स्थानों पर एपीआई को रेस्ट एपीआई के रूप में देखें?


21
@ जॉन सॉन्डर्स: यह एक संभावित डुप्लिकेट कैसे है? दूसरे व्यक्ति को स्पष्ट रूप से पता है कि REST क्या है, जबकि दूसरी ओर, नाथन भ्रमित है।
नकली कोड बंदर राशिद

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

1
REST वेब सेवाओं के निर्माण के लिए नियमों का एक समूह है। अगर एक API उन नियमों के अनुसार बनाया गया है तो यह REST API है। मैंने अपने रबर डक को REST कैसे समझाया, इसके कुछ नियम अनौपचारिक रूप से बताते हैं।
यूजर 42

जवाबों:


127

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

पहले रयान टोमाको की पोस्ट पढ़ें मैंने अपनी पत्नी को कैसे समझाया ; यह एक शानदार शुरुआत है। फिर फील्डिंग के वास्तविक शोध प्रबंध को पढ़ें। यह इतना उन्नत नहीं है, न ही यह लंबा है (छह अध्याय, 180 पृष्ठ)! (मुझे पता है कि आप बच्चों को स्कूल में कम पसंद करते हैं)।

संपादित करें: मुझे लगता है कि REST को समझाने की कोशिश करना व्यर्थ है। इसमें मापनीयता, दृश्यता (स्टेटलेस) आदि जैसी कई अवधारणाएँ हैं, जिन्हें पाठक को समझने की आवश्यकता है, और वास्तविक शोध प्रबंध को समझने के लिए सबसे अच्छा स्रोत है। यह POST / GET आदि से बहुत अधिक है।


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

जब डेवलपर्स REST को नियोजित करने की कोशिश करते हैं और इसे केवल अपने कोड पर करने की कोशिश करते हैं (मन में REST के साथ पूरे सिस्टम की योजना के बिना), नरक आता है :-)
karatedog

@Anders, REST को ध्यान में रखते हुए कि यह क्या है, आप कैसे REST बनाम वेब सेवाओं का अनुपालन कर सकते हैं?
कैदी


1
हो सकता है कि यह अध्याय पूरे शोध प्रबंध को पढ़ने के बजाय पर्याप्त होगा: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
andilabs

74

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

REST के बारे में सोचने का सबसे मूल तरीका आपके वेब अनुप्रयोगों के URL को फ़ॉर्मेट करने का एक तरीका है। उदाहरण के लिए, यदि आपके संसाधन को "पोस्ट" कहा जाता है, तो:

/posts यह प्रदर्शित करने के लिए एक उपयोगकर्ता सभी पदों तक कैसे पहुंचेगा।

/posts/:id ऐसा होगा कि कोई उपयोगकर्ता अपनी विशिष्ट आईडी के आधार पर किसी व्यक्तिगत पोस्ट को कैसे एक्सेस करेगा और देखेगा।

/posts/new ऐसा होगा कि आप एक नई पोस्ट बनाने के लिए एक फॉर्म कैसे प्रदर्शित करेंगे।

POST अनुरोध भेजना /usersयह होगा कि आप वास्तव में डेटाबेस स्तर पर एक नया पोस्ट कैसे बनाएंगे

एक PUT अनुरोध भेजना /users/:idयह होगा कि आप किसी दिए गए पोस्ट की विशेषताओं को कैसे अपडेट करेंगे, फिर से एक अद्वितीय आईडी द्वारा पहचाना जाएगा।

DELETE अनुरोध भेजना /users/:idयह होगा कि आप किसी दिए गए पद को कैसे हटाएंगे, फिर से एक अद्वितीय आईडी द्वारा पहचाना जाएगा।

जैसा कि मैं इसे समझता हूं, REST पैटर्न को मुख्य रूप से रूबी फ्रेमवर्क पर रूबी द्वारा लोकप्रिय (वेब ​​ऐप्स के लिए) किया गया था, जो Restful मार्गों पर एक बड़ा जोर देता है। मैं इसके बारे में गलत हो सकता है।

मैं इसके बारे में बात करने के लिए सबसे योग्य नहीं हो सकता है, लेकिन यह मैंने कैसे सीखा है (विशेषकर रेल विकास के लिए)।

जब कोई "रेस्ट एपि" का संदर्भ लेता है, तो आमतौर पर उनका मतलब एक एपि होता है जो डेटा प्राप्त करने के लिए रेस्टफुल यूआरएल का उपयोग करता है।


2
आप भाग्यशाली हैं, क्योंकि REST REST सिद्धांतों पर बनाया गया है और यदि आप Rails टूल का उपयोग करते हैं, तो आपका कोड Restful होगा। हालाँकि, वहाँ कोडर हैं जो REST के बारे में जैक को नहीं समझते, वे कोड करते हैं कि वे क्या चाहते हैं और अंत में वे इस 'URL स्वरूपण' का उपयोग करते हैं क्योंकि यह ट्रेंडी है।
कराटेग

8
इस उत्तर में कभी भी / उपयोगकर्ताओं का उपयोग किया गया है, क्या यह / पोस्ट नहीं होना चाहिए?
मयूरेश श्रीवास्तव

@MayureshSrivastava ध्यान दें कि PUT के उदाहरण हैं: id और POST के उदाहरण नहीं हैं: id। बाकी की कहानी के लिए गूगल। (POST: नॉन-सेफ, नॉन-इडम्पोटेंट; PUT: नॉन-सेफ, आइडम्पोटेंट)
Ajeet Ganga

38

RESTएक वास्तुकला शैली और नेटवर्क-आधारित सॉफ़्टवेयर आर्किटेक्चर के लिए एक डिज़ाइन है

RESTअवधारणाओं को संसाधन के रूप में संदर्भित किया जाता है। किसी संसाधन का प्रतिनिधित्व स्टेटलेस होना चाहिए। यह कुछ मीडिया प्रकार के माध्यम से दर्शाया गया है। मीडिया प्रकार में शामिल हैं XML, JSON, और RDF। घटकों द्वारा संसाधनों में हेरफेर किया जाता है। घटक एक समान यूनिफ़ॉर्म इंटरफेस के माध्यम से संसाधनों का अनुरोध और हेरफेर करते हैं। HTTP के मामले में, इस इंटरफेस मानक HTTP ऑप्स जैसे होते हैं GET, PUT, POST, DELETE

RESTआमतौर पर HTTPHTTP पर प्रयोग किया जाता है , मुख्य रूप से HTTP की सादगी और Restful सिद्धांतों के लिए इसकी बहुत प्राकृतिक मानचित्रण के कारण। REST हालांकि किसी विशिष्ट प्रोटोकॉल से बंधा नहीं है।

मौलिक अनुष्ठान सिद्धांत

क्लाइंट-सर्वर संचार

क्लाइंट-सर्वर आर्किटेक्चर में चिंताओं का एक अलग अलगाव है। रैस्टफुल स्टाइल में निर्मित सभी एप्लिकेशन को सिद्धांत रूप में क्लाइंट-सर्वर भी होना चाहिए।

राज्यविहीन

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

संचित करने योग्य

कैश की कमी का उपयोग किया जा सकता है, इस प्रकार प्रतिक्रिया डेटा को कैचीबल या नहीं-केचबल के रूप में चिह्नित किया जा सकता है। कैचवेबल के रूप में चिह्नित किसी भी डेटा को उसी बाद के अनुरोध की प्रतिक्रिया के रूप में पुन: उपयोग किया जा सकता है।

यूनिफ़ॉर्म इंटरफ़ेस

सभी घटकों को एक समान वर्दी इंटरफेस के माध्यम से बातचीत करनी चाहिए। क्योंकि इस इंटरफ़ेस के माध्यम से सभी घटक इंटरैक्शन होते हैं, विभिन्न सेवाओं के साथ बातचीत बहुत सरल है। इंटरफ़ेस वही है! इसका अर्थ यह भी है कि अलगाव में कार्यान्वयन परिवर्तन किए जा सकते हैं। इस तरह के परिवर्तन, मौलिक घटक इंटरैक्शन को प्रभावित नहीं करेंगे क्योंकि वर्दी इंटरफ़ेस हमेशा अपरिवर्तित रहता है। एक नुकसान यह है कि आप इंटरफ़ेस के साथ फंस गए हैं। यदि इंटरफ़ेस बदलकर एक विशिष्ट सेवा के लिए एक अनुकूलन प्रदान किया जा सकता है, तो आप भाग्य से बाहर हैं क्योंकि REST इसे प्रतिबंधित करता है। उज्ज्वल पक्ष पर, हालांकि, REST वेब के लिए अनुकूलित है, इसलिए HTTP पर REST की अविश्वसनीय लोकप्रियता है!

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

REST और उपरोक्त सिद्धांतों पर अधिक जानकारी के लिए REST डिज़ाइन प्रिंसिपलों पर इस ब्लॉग पोस्ट को देखें ।


15

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

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

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

पढ़ने योग्य:


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

@ एंडर्स - उन्होंने कहा कि वह एक REST API को देख रहे थे और उन्होंने सोचा कि यह Webservices का उपयोग करने का एक तरीका है। आप REST का उपयोग उस तरह से कर सकते हैं और उस क्षमता में यह सोप को पूरा करने के लिए बहुत कुछ प्रदान करता है। दुनिया के सबसे बड़े रेस्टफुल एप्लिकेशन के रूप में वेब के बारे में बात करना भी संभव है, लेकिन यह वास्तव में यह स्पष्ट नहीं करता है कि आप किस लिए REST API का उपयोग करेंगे।
मार्क

यह वास्तव में मेरी मुख्य समस्या रही है, उसी अवधारणा में REST और SOAP को देखना। ऐसा लगता है कि API डिज़ाइन में केवल RESTful हैं।
कैदी

4

http://en.wikipedia.org/wiki/Representational_State_Transfer

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


3
शायद यह सिर्फ मुझे है, लेकिन मुझे उचित उद्धरण के साथ स्टैकओवरफ्लो पर प्रासंगिक जवाब देखना पसंद है। बस मुझे हास्य और मान लीजिए कि विकिपीडिया पोफ चला गया। आपका लिंक क्या अच्छा है तो हम्म? :)
नकली कोड बंदर राशिद

1
@ हेक देखा: यह आपके उत्तर में नहीं होना चाहिए?
नकली कोड बंदर राशिद

मैंने अभी एडिट फीचर पर ध्यान दिया है। :)
हैक करें

1
@karatedog: HTTP के साथ REST प्राप्त किया जा सकता है, लेकिन यह विभिन्न डेटा ट्रांसफर विधियों के साथ किया जा सकता है।
हैक

1
यह HTTP प्रोटोकॉल है जिसके बारे में आप लिख रहे हैं, REST एक आर्किटेक्चर है।
करातयोग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.