REST vs RESTful बनाम "सामान्य" वेब सेवा - समान या नहीं?

Question

मैंने REST और / या RESTful अनुप्रयोगों पर कुछ परिभाषाओं और चर्चा को पढ़ा है, लेकिन मुझे अभी भी इसका वास्तविक अर्थ समझ नहीं आया है।

मैं आमतौर पर उन ऐप्स के साथ काम करता हूं जो या तो GET के माध्यम से डेटा प्राप्त करते हैं या POST के माध्यम से कुछ वेब सेवा (आमतौर पर एक PHP स्क्रिप्ट) को डेटा भेजते हैं जो या तो डेटाबेस से डेटा प्राप्त करते हैं या डेटाबेस में लिखते हैं।

अब, क्या यह एक RESTful ऐप है? यदि नहीं, तो RESTful ऐप क्या होगा? रेस्टफुल कॉन्सेप्ट और मैंने अभी तक जिस कॉन्सेप्ट पर काम किया है, उसमें क्या अंतर है? कृपया एक उदाहरण के माध्यम से समझाएं।

इसके अलावा, कोई REST के बारे में बात कर रहा है और कोई Restful ऐप्स के बारे में। मैंने पाया कि REST शब्द सैद्धांतिक अवधारणा को संदर्भित करता है, जबकि Restful का उपयोग तब किया जाता है जब हम विशिष्ट ऐप के बारे में बात करते हैं। क्या यह सही है या REST और RESTful ऐप्स के बीच वास्तविक अंतर हैं?

Comments

यदि आप केवल GET या POST मापदंडों से जानकारी खींचने के लिए अपने सभी सर्वलेट्स का निर्माण कर सकते हैं (कॉल से पहले स्थानीय रूप से सहेजे गए कुछ भी नहीं), तो आप ठीक से REST लागू कर रहे हैं। दूसरे शब्दों में, सर्वर MVC में मॉडल की भूमिका निभाता है कि यह नियंत्रण में नहीं है, लेकिन बस कुछ कार्यों को करने के लिए जो दिया जाता है उसका उपयोग करता है। आशा है कि यह थोड़ा बेहतर समझाता है।

— नील

@ नील मैं दूसरी तरफ हूं - मोबाइल ऐप। यह एक ग्राहक है जो वेब सेवा का उपयोग करता है और POST और GET के माध्यम से इसके साथ संचार करता है। सभी वेब सेवा किसी और द्वारा बनाई गई हैं और मैंने जो कुछ भी किया था, उनका उपयोग कर रहा था। लेकिन शब्दावली ने मुझे भ्रमित कर दिया। तो, अगर मैं HTTP चैनल और HttpGet / HttpPost ऑब्जेक्ट्स का उपयोग कर रहा हूं, तो मैं एक Restful ऐप के साथ काम कर रहा हूं, है ना?

— देवीदेव

जरुरी नहीं। यह जानने का कोई तरीका नहीं है कि यह एक RESTful ऐप है अगर आपको नहीं पता कि सर्वर कैसे किया जाता है क्योंकि यह कुछ बाधाओं का उल्लंघन कर सकता है। अगर यह लगातार परिणाम देता है, तो यह संभवत: RESTful है।

— नील

@ नील ओह, मैं अब मिलता हूं। सर्वर पर RESTful किया जाता है। और अगर मैं एक पोस्ट ऑब्जेक्ट को अनुरोध के साथ भेजता हूं (प्रत्येक पैरामीटर को व्यक्तिगत रूप से नहीं) तो यह शायद एक REST दृष्टिकोण है। जहां तक ​​ग्राहक (मोबाइल एप) की बात है, तो यह परवाह नहीं करता कि यह REST है या नहीं क्योंकि कोडिंग समान है। क्या मुझे यह सही लगा है?

— देवीदेव

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

— नील

Answer 1

RESTful अनुप्रयोगों की प्रमुख विशेषताएँ हैं: सभी संचार http GET, POST, PUT, DELETE और सभी वस्तुओं के माध्यम से होते हैं, जिन्हें फॉर्म के एक मानक URL के माध्यम से संबोधित किया जाता है http://your.site.com/salesapp/salesperson/0000001/detailsअर्थात केवल कोई शुद्ध URL जिसमें कोई पैरामीटर नहीं है आदि URL GET की पहचान करता है। , POST, PUT, DELETE पहचानता है कि आप इसे क्या करना चाहते हैं।

ऐसा करने का मुख्य कारण यह है कि आपके पास स्वचालित रूप से एक स्टेटलेस सेवा होती है जिसे संतुलित, असफल आदि पर लोड किया जा सकता है।

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

Comments

ओह, अब तक मैंने PUT या DELETE का उपयोग नहीं किया है (मोबाइल एप्लिकेशन आमतौर पर केवल GET और POST करते हैं), लेकिन यह वास्तव में ऐसा लगता है कि मैंने क्या किया है और इस समय कर रहा हूं। यह सिर्फ इतना है कि क्लाइंट ने REST * की शर्तों का उपयोग नहीं किया, बल्कि "वेब सेवा" और "php स्क्रिप्ट"

— deviDave

जेम्स, क्या आप बता सकते हैं कि क्वेरी पैरामीटर से क्यों बचा जाए? उदाहरण के लिए, मैं कैसे व्यक्त करूं कि मैं झूठे पदानुक्रम की शुरुआत किए बिना संसाधनों को एक विशेष तरीके से फ़िल्टर करना चाहता हूं?

— गैरी रोव

@ गैरीवाह: URL (बिना मापदंडों के) उस संसाधन की पहचान करता है जिसे आप हेरफेर करना चाहते हैं। आपके पास अभी भी पैरामीटर हो सकते हैं लेकिन संसाधन की पहचान करने में इनका उपयोग नहीं किया जाता है। एक निर्देशिका पर एक GET का उदाहरण दें (/ के साथ समाप्त होने वाला URL) निर्देशिका में संसाधनों की सूची लौटाए। URL पर एक पैरामीटर का उपयोग फ़िल्टर या सॉर्ट ऑर्डर या ऐसा कुछ निर्दिष्ट करने के लिए किया जा सकता है।

— मार्टिन यॉर्क

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

— गैरी रोव

REST को एप्लिकेशन को URL-आधारित होने की आवश्यकता नहीं है और न ही इसके लिए आपको GET, POST, DELETE, आदि जैसी क्रियाएं करने की आवश्यकता है, हालाँकि, WebApp के लिए, URL एकमात्र विकल्प और पूर्वोक्त क्रिया है।

— नवाज

Answer 2

REST का अर्थ है प्रतिनिधि राज्य अंतरण। यदि आपका सॉफ्टवेयर REST बाधाओं के अनुरूप है तो इसे RESTful माना जाता है।

ठीक है, अब जब मैंने बेशर्मी से विकिपीडिया से भाग लिया है, तो इसका वास्तव में क्या मतलब है? इसका प्रभावी रूप से मतलब है कि इनबिल्ट HTTP कमांड जैसे कि GET, POST, PUT, DELETE और कुछ अन्य रेयर का उपयोग करके क्लाइंट और सर्वर के बीच आगे-पीछे संचार करना।

क्या आप कर रहे हैं लगता है जैसे कि एक RESTFul ऐप। हालाँकि, अच्छी तरह से डिजाइन किए गए और ढेर ओ रंक RESTFul वेब सेवाओं के बीच एक बड़ा अंतर है। उदाहरण के लिए, GET के दूसरे छोर पर स्थित PHP कोड राज्य परिवर्तन को निष्पादित कर सकता है, जिसे गलत माना जाएगा क्योंकि GET को केवल पढ़ने के लिए ऑपरेशन के रूप में देखा जाता है। POST (नया) और PUT (प्रतिस्थापित) का उपयोग कैसे किया जाता है, इसके बीच सूक्ष्म अंतर हैं।

इस पर विकिपीडिया लेख वास्तव में अच्छा है, इसलिए मैं यहां रुकूंगा।

Comments

अब तक, मैंने GET (HttpGet) का उपयोग सामग्री लाने के लिए और POST (HttpPost) को डेटाबेस की सामग्री को दर्ज करने / बदलने के लिए किया था। मैंने इसे HttpPost के पैरामीटर के रूप में भेजा और वेब सर्वर पर PHP स्क्रिप्ट ने इन मापदंडों को SQL कोड में बदल दिया। क्या यह Restful ऐप है? मुझे एक अवधारणा में दिलचस्पी है, न कि PHP स्क्रिप्ट में कितनी अच्छी तरह से किया गया है। मैंने इसे नहीं बनाया है।

— देवीदेव

मैं उस मामले में PUT के उपयोग की जांच करूंगा जहां आप सामग्री की जगह ले रहे हैं , इसका अधिक मुहावरेदार REST हमेशा POST के उपयोग से।

— Martijn Verburg

हां, ऐसे मामले में मैं PUT का उपयोग करूंगा।

— देवीदेव

+1 यह ध्यान देने के लिए कि GET को सही तरीके से लागू किया जाना है (यानी यह एक प्रकार से आलस्यपूर्ण है)। शुरुआती दिनों में ऐसी मौलिक त्रुटि।

— गैरी रोव

@deviDave आप पाच में भी देखना चाह सकते हैं जो एक संसाधन के भाग को अद्यतन करने के लिए डिज़ाइन किया गया है। जैसा कि मार्टिन ने सही बताया कि PUT पूरे संसाधन को बदलने के लिए है।

— गैरी रोवे

Answer 3

आगे जाने से पहले, यह संबंधित प्रश्न आपकी मदद कर सकता है

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

कई वेब अनुप्रयोगों RESTful होने का दावा है, लेकिन वास्तव में केवल आंशिक रूप से अधिक से अधिक अनुरूप कर रहे हैं करने के लिए बाकी प्रतिबन्ध (के रूप में मार्टिन Verburg भी अपने जवाब में संदर्भित किया गया है)। मैं उन्हें बस यहाँ सूचीबद्ध करूँगा, लेकिन मैं आपसे लेख पढ़ने का आग्रह करता हूँ:

• क्लाइंट सर्वर
• cacheable
• स्तरित प्रणाली
• मांग पर कोड (वैकल्पिक)

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

आपके ग्राहक से यह अपेक्षा की जाएगी:

• प्रासंगिक क्रियाओं को करने के लिए HTTP वर्ब्स (जैसे GET, POST, PUT, DELETE, विकल्प, PATCH) का उपयोग करें
• हेडर स्वीकार करें और कंटेंट-टाइप हेडर को समझें (जैसे आपको कुछ ऐसे XML मिलते हैं, जिन्हें आपने पहले कभी नहीं देखा होगा, लेकिन आप अपने उपयोगकर्ता को प्रस्तुत करने के लिए क्लाइंट-साइड डोमेन मॉडल बनाने के लिए संदर्भित XSD का उपयोग कर सकते हैं)
• आपके द्वारा समझे जाने वाले सामग्री-प्रकार में दिए गए लिंक का अनुसरण करें (उदाहरण के लिए अपना उपयोगकर्ता या अपना आवेदन प्राप्त करने के लिए यह अनुमान लगाएं कि <link rel="pay" href="http://example.org/orders(1)/payment">HTML में कोई पोस्ट XML के साथ एक भुगतान संसाधन बनाने के लिए एक राज्य संक्रमण व्यक्त करता है जिसमें कुछ XML वाला शरीर क्रेडिट कार्ड नंबर जैसे भुगतान विवरण का प्रतिनिधित्व करता है। , राशि और इतने पर)
• HTTP स्थिति कोड की विस्तृत श्रृंखला पर सही ढंग से प्रतिक्रिया करें

यदि यह ऊपर करता है तो इसे REST क्लाइंट के रूप में माना जा सकता है, आप इसे "RESTful ऐप" कह सकते हैं, लेकिन इसके बजाय इसका मतलब यह होगा कि आप REST का उपयोग क्लाइंट पक्ष पर कर रहे हैं जो कि बचने के लिए सबसे अच्छा है। अवधि।

Answer 4

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

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

Comments

1 पैराग्राफ के लिए अपवोट। इसलिए संक्षिप्त करें। धन्यवाद!

— देवीदेव

एक बात और, यह देखने के लिए कि क्या मुझे यह ठीक लगा। यदि मैं (मेरा ऐप) REST सेवा का ग्राहक है, तो मैं एक ग्राहक के रूप में मामला नहीं करता हूं यदि कोई सेवा Restful है या नहीं, क्योंकि मेरी कोडिंग हमेशा समान (httpget, लंगोट, आदि) है? यह सिद्धांत केवल सर्वर स्क्रिप्ट / ऐप के स्वामी के लिए मायने रखता है?

— देवीदेव

REST इंटरफेस के शब्दार्थ को डिजाइन करने के लिए एक दिशानिर्देश है। अंतर्निहित तकनीक HTTP है कि इंटरफ़ेस रेस्टफुल है या नहीं (लेकिन XML-RPC या SOAP जैसी अन्य परतें Restful इंटरफेस के लिए प्रासंगिक नहीं हैं), इसलिए आप हमेशा एक ही HTTPget, रिपोटॉप आदि का उपयोग करते हैं, लेकिन आप नेटवर्क विफलता को अलग तरीके से संभालते हैं।

— Jan Hudec

जोड़ने के लिए, SMTP एक Restful इंटरफ़ेस है, हालांकि यह GET, PUT आदि से अलग क्रियाओं और एक अलग अंतर्निहित प्रोटोकॉल का उपयोग करता है, अवधारणा एक ही है - आप एक सर्वर पर निष्क्रिय क्रिया आधारित आदेश भेजते हैं।

— gbjbaanb

सभी REST अनुरोध बेकार नहीं हैं। उदाहरण के लिए, कई बार POST जारी करने के परिणामस्वरूप बहुत सारे नए संसाधन मिलेंगे।

— गैरी रोवे