161

जाहिर है, आरईएसटी HTTP का उपयोग करने के बारे में सम्मेलनों का एक सेट है । मुझे आश्चर्य है कि इन सम्मेलनों से कौन सा लाभ मिलता है। क्या कोई जानता है?

rest

— दिमित्री सी।
स्रोत

5

यह भी देखें कि हमें आराम क्यों करना चाहिए?

— WReach

162

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

इसके बजाय बेतरतीब ढंग से नामित सेटर और गेटर यूआरएल होने और का उपयोग कर के GETसभी टिककर खेल के लिए और POSTsetters सभी के लिए, हमें उन URL संसाधनों की पहचान के लिए प्रयास करते हैं, और उसके बाद HTTP क्रियाओं का उपयोग GET, POST, PUTऔर DELETEउन्हें सामान करना है। इसलिए इसके बजाय

GET /get_article?id=1
POST /delete_article   id=1

तुम करोगे

GET /articles/1/
DELETE /articles/1/

और फिर POSTऔर PUT"बनाने" और "अपडेट" संचालन के अनुरूप है (लेकिन कोई भी इस बात से सहमत नहीं है कि कौन सा रास्ता है)।

मुझे लगता है कि कैशिंग तर्क, गलत हैं क्योंकि क्वेरी स्ट्रिंग कर रहे हैं आम तौर पर कैश की गई है, और उन्हें उपयोग करने के लिए इसके अलावा आप वास्तव में जरूरत नहीं है। उदाहरण के लिए django ऐसा कुछ बहुत आसान बनाता है, और मैं यह नहीं कहूंगा कि यह बाकी था:

GET /get_article/1/
POST /delete_article/     id=1

या यहां तक कि क्रिया को URL में शामिल करें:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

उस मामले में GETसाइड-इफेक्ट्स के बिना कुछ का मतलब है, और POSTकुछ का मतलब है जो सर्वर पर डेटा को बदलता है। मुझे लगता है कि यह शायद थोड़ा स्पष्ट और आसान है, खासकर जब आप पूरी PUT-vs- POSTचीज़ से बच सकते हैं । साथ ही अगर आप चाहते हैं तो आप और क्रियाओं को जोड़ सकते हैं, इसलिए आप कृत्रिम रूप से HTTP के लिए बाध्य नहीं हैं। उदाहरण के लिए:

POST /hide/article/1/
POST /show/article/1/

(या जो भी हो, उदाहरणों के बारे में सोचना मुश्किल है जब तक वे नहीं होते!)

इसलिए निष्कर्ष में, केवल दो फायदे हैं जिन्हें मैं देख सकता हूं:

आपका वेब एपीआई क्लीनर / समझने और खोजने में आसान हो सकता है।
किसी वेबसाइट के साथ डेटा सिंक्रोनाइज़ करते समय, शायद REST का उपयोग करना आसान होता है क्योंकि आप बस synchronize("/articles/1/")या जो भी कह सकते हैं । यह आपके कोड पर बहुत अधिक निर्भर करता है।

हालाँकि मुझे लगता है कि कुछ बहुत बड़े नुकसान हैं:

सभी कार्रवाइयां आसानी से CRUD को मैप नहीं करती हैं (बनाएं, पढ़ें / पुनर्प्राप्त करें, अपडेट करें, हटाएं)। आप ऑब्जेक्ट प्रकार संसाधनों के साथ भी व्यवहार नहीं कर सकते हैं।
यह संदिग्ध लाभों के लिए अतिरिक्त प्रयास है।
भ्रम है कि किस तरह के दौर PUTऔर POSTहैं। अंग्रेजी में उनका मतलब ऐसी ही चीजों से है ("मैं दीवार पर नोटिस लगाने / पोस्ट करने जा रहा हूं।")।

इसलिए निष्कर्ष में मैं कहूंगा: जब तक आप वास्तव में अतिरिक्त प्रयास पर नहीं जाना चाहते हैं, या यदि आपकी सेवा सीआरयूडी संचालन के लिए वास्तव में अच्छी तरह से मैप करती है, तो अपने एपीआई के दूसरे संस्करण के लिए रीस्ट को बचाएं।

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

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

जो हास्यास्पद है। Facebook का API बहुत अच्छा IMO है, तो आइए देखें कि वे क्या करते हैं:

डिफ़ॉल्ट रूप से, जब आप क्वेरी बनाते हैं, तो अधिकांश ऑब्जेक्ट गुण वापस आ जाते हैं। आप उन फ़ील्ड (या कनेक्शन) को चुन सकते हैं जिन्हें आप "फ़ील्ड" क्वेरी पैरामीटर के साथ लौटाते हैं। उदाहरण के लिए, यह URL केवल आईडी, नाम और बेन की तस्वीर लौटाएगा: https://graph.facebook.com/bgolub?fields=id,name,picture

मुझे नहीं पता कि आप REST के साथ ऐसा कुछ कैसे करेंगे, और यदि आपने किया कि क्या यह अभी भी REST के रूप में गिना जाएगा। मैं निश्चित रूप से किसी को भी अनदेखा करूँगा जो आपको यह बताने की कोशिश करता है कि आपको ऐसा नहीं करना चाहिए (विशेषकर यदि कारण "क्योंकि यह REST नहीं है")!

— Timmmm
स्रोत

4

HTTP RFC के अनुसार POST और PUT का उपयोग किया जाना है। इस स्थिति में, PUT का अर्थ है कि किसी विशिष्ट स्थान पर कुछ बनाना / अपडेट करना - जो घटित होता है, यह इस बात पर निर्भर करता है कि URI में कुछ पहले से ही है (और यह भी बहुत ही अच्छा है), जबकि POST का अर्थ है कि आप वेब सेवा से यह निर्धारित करने के लिए कहें कि आपको क्या करना है। इसे भेजना - और फिर यह आपको यूआरआई लौटाता है (इसलिए यह केवल बना है)। वास्तव में अंग्रेजी के बारे में शिकायत नहीं कर सकते, न कि जब कंप्यूटर से किसी भी चीज का जिक्र करते समय DELETE का उपयोग करना पूरी तरह से बंद हो। मैं इस बारे में सोच रहा हूं कि आपके संपादन में लाए गए मुद्दे के संबंध में क्या करना है, हालांकि: P

— Nan L

7

Facebook API उदाहरण मुझे REST की तरह लगता है (वास्तव में कहीं अधिक ताकि URL में क्रियाओं का उपयोग करके आपके उदाहरण)। कोई कारण नहीं है कि क्वेरी पैरामीटर RESTful नहीं हो सकता है, यह उन रास्तों का उपयोग करने के लिए सिर्फ अच्छा अभ्यास है जहां डेटा पदानुक्रम में व्यवस्थित किया जा सकता है।

— जस्टिन एमरी

5

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

— सिनास्टेटिक

3

-1, REST कुछ बहुत विशिष्ट है - जैसा कि रॉय फील्डिंग ने बताया था जब उन्होंने इसका आविष्कार किया था। इस जवाब को देखें । विशेष रूप से: "क्लाइंट को केवल प्रारंभिक यूआरआई पता होना चाहिए, और बाद में नेविगेट करने या कार्रवाई करने के लिए सर्वर-आपूर्ति विकल्पों से चुनता है।" । मूल रूप से, अगर कोई API दस्तावेज़ का कोई भाग समापन बिंदुओं के लिए होता है, उदाहरण के लिए, "उपयोगकर्ता आईडी दी गई है, तो आप उपयोगकर्ता की जानकारी प्राप्त कर सकते हैं /user/{id}, तो यह आराम करने योग्य नहीं है। विचार करें: क्या आपके ब्राउज़र को यह जानने के लिए पूर्वप्रोग्रामित आना पड़ता है कि स्टैकओवर प्रश्न के लिए HTML कैसे प्राप्त करें। पृष्ठ?

— क्लाउडीउ

1

(जारी ...) कि अन्य लोग इस शब्द का दुरुपयोग करते हैं वह क्या है यह नहीं बदलता है। अस्वीकरण, यद्यपि: मैं अभी भी सीख रहा हूं कि REST क्या है और यह मेरे लिए हाल ही में क्लिक किया गया है।

— क्लाउडीयू

47

सीधे शब्दों में कहें तो REST का मतलब है HTTP का उपयोग करना जिस तरह से यह होना चाहिए।

REST के बारे में रॉय फील्डिंग के शोध प्रबंध पर एक नज़र डालें । मुझे लगता है कि वेब डेवलपमेंट करने वाले हर व्यक्ति को इसे पढ़ना चाहिए।

एक नोट के रूप में, रॉय फील्डिंग HTTP प्रोटोकॉल के पीछे के प्रमुख ड्राइवरों में से एक है, साथ ही साथ।

कुछ अडवांस का नाम देने के लिए:

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

— एमिल इवानोव
स्रोत

11

"सरल": HTTP से अधिक सरल क्यों है?

— दिमित्री सी।

5

"आपको व्यवस्थित करने में मदद करता है": तो केवल GET और POST का उपयोग करते समय यह संगठन अधिक कठिन है?

— दिमित्री सी।

1

"यह नए ग्राहकों के लिए आपके एप्लिकेशन का उपयोग करना आसान बनाता है": यह REST बनाम सादे HTTP के बारे में है, है ना?

— दिमित्री सी।

23

बाकी बाधाओं का सामना करना निश्चित रूप से सरल नहीं है। चार मानक क्रियाओं में जटिल व्यावसायिक संचालन को निचोड़ना वास्तव में कभी-कभी कठिन होता है। हालांकि, जब अच्छी तरह से किया जाता है, तो अंतिम परिणाम समझने के लिए सरल हो सकता है, लेकिन कुछ भी हो सकता है।

— डारेल मिलर

6

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

— एमिल इवानोव

31

सीधे शब्दों में कहें: कोई भी ।

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

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

1. सरल

REST के साथ आपको अपने सर्वर-साइड और क्लाइंट-साइड स्क्रिप्ट के लिए अतिरिक्त संचार परत की आवश्यकता है => यह वास्तव में गैर-REST HTTP के उपयोग से अधिक जटिल है।

2. कैशिंग

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

3. संगठन

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

4. प्रयोग करने में आसान / कार्यान्वित

सच नहीं है। यह सब इस बात पर निर्भर करता है कि आप अपने आवेदन को कितनी अच्छी तरह व्यवस्थित और दस्तावेजित करते हैं। REST जादुई रूप से आपके आवेदन को बेहतर नहीं बनाएगा।

— पेट्र पेलर
स्रोत

3

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

— स्कॉट शूल्थेस

2

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

— स्कॉट शुलथेस

4

"REST आपको चीजों को व्यवस्थित करने में मदद नहीं करता है। यह आपको सर्वर-साइड लाइब्रेरी द्वारा समर्थित एपीआई का उपयोग करने के लिए मजबूर करता है।" मुझे यकीन नहीं है कि आप इसका क्या मतलब है। यह एक अतिरिक्त सर्वर साइड फ्रेमवर्क का उपयोग किए बिना एक RESTful API बनाने के लिए (और REST API के निर्माण से अधिक कठिन नहीं है) पूरी तरह से संभव है।

— माइकल ओ।

2

"REST के साथ आपको अतिरिक्त संचार परत की आवश्यकता है" - हंबग, आप अपने मौजूदा HTTP पुस्तकालय का उपयोग ठीक कर सकते हैं।

— सोरेन बोइसन

1

@ सोरेनबोइसन यह उत्तर थोड़ा पुराना है। मुझे शायद चीजों की वर्तमान स्थिति को और अधिक प्रतिबिंबित करने के लिए इसे अपडेट करना चाहिए।

— पेट्र पेलर

23

IMHO सबसे बड़ा फायदा जो REST सक्षम करता है, वह क्लाइंट / सर्वर कपलिंग को कम करने में है। मौजूदा क्लाइंट्स को तोड़े बिना समय के साथ REST इंटरफेस को विकसित करना बहुत आसान है।

— डारेल मिलर
स्रोत

4

क्या आप एक उदाहरण दे सकते हैं? धन्यवाद!

— Jan 38ankowski

3

क्या यह इस बात पर निर्भर नहीं करेगा कि आपके गैर-रीस्ट एपीआई को कैसे हटाया गया?

— जॉनी

@ जॉनी यह संभव है, लेकिन संभावना नहीं है। REST की बाधाओं को घटकों के स्वतंत्र विकास को स्पष्ट रूप से सक्षम करने के लिए चुना गया था। यदि आपको समान बाधाओं को लागू किए बिना इसे बेहतर करने का एक तरीका मिल गया है, तो मुझे यकीन है कि बहुत से लोग इसके बारे में सुनना पसंद करेंगे।

— डारेल मिलर

@DarrelMiller क्या आप विस्तृत कर सकते हैं कि REST क्लाइंट / सर्वर युग्मन को गैर REST http दृष्टिकोण से बेहतर कैसे कम करता है? मेरा मानना है कि आप उस बिंदु की ओर इशारा कर रहे हैं जो टिमम ने अपने उत्तर में कहा था। कृपया मेरा Timmmm जवाब के तहत नवीनतम टिप्पणी को देख

— emilly

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

— डारेल मिलर

15

खोजे जाने

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

अन्य उपकरणों के साथ संगतता

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

मानकीकृत क्रिया नाम

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

मानकीकृत स्थिति

यदि आपके पास GETकोई ऐसा संसाधन है जो मौजूद नहीं है, तो आप 404RESTful API में त्रुटि प्राप्त कर सकते हैं । इसे नॉन-रेस्टफुल एपीआई के साथ कंट्रास्ट करें, जो हो सकता {error: "Not found"}है कि भगवान में लिपटे हुए कितने परतों को जानता हो। यदि आपको दूसरी तरफ डेवलपर को संदेश लिखने के लिए अतिरिक्त स्थान की आवश्यकता है, तो आप हमेशा प्रतिक्रिया के शरीर का उपयोग कर सकते हैं।

उदाहरण

एक ही कार्यक्षमता के साथ दो एपीआई की कल्पना करें, एक आरईएसटी के बाद और दूसरा नहीं। अब उन एपीआई के लिए निम्नलिखित ग्राहकों की कल्पना करें:

RESTful:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

एचटीटीपी:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

अब निम्नलिखित प्रश्नों पर विचार करें:

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

— BoppreH
स्रोत

यह एक संपूर्ण सूची नहीं है और इसमें केवल बहुत ही व्यावहारिक फायदे हैं।

— BoppreH

यह एक बहुत ही स्मार्ट जवाब है, मैं सराहना करता हूं।

— एरालपब

10

मैं रयान टोमाको की हाउ आई एक्सप्लेड रेस्ट टू माय वाइफ पर एक नज़र डालने की सलाह देता हूं

थर्ड पार्टी एडिट

Waybackmaschine लिंक से अंश:

एक उदाहरण के बारे में कैसे। आप एक शिक्षक हैं और छात्रों का प्रबंधन करना चाहते हैं:

वे किस वर्ग में हैं
उन्हें क्या ग्रेड मिल रहा है,
आपातकालीन संपर्क,
आपके द्वारा पढ़ी जाने वाली पुस्तकों आदि के बारे में जानकारी।

यदि सिस्टम वेब-आधारित हैं, तो संभवतः इसमें शामिल प्रत्येक संज्ञा के लिए एक URL है student, teacher, class, book, room, etc:। ... यदि प्रत्येक URL के लिए एक मशीन पठनीय प्रतिनिधित्व होता है, तो यह सिस्टम पर नए टूल को लागू करने के लिए तुच्छ होगा क्योंकि यह सभी जानकारी एक मानक तरीके से उपभोग्य होगी। ... आप एक देशव्यापी प्रणाली का निर्माण कर सकते थे जो परीक्षण स्कोर एकत्र करने के लिए व्यक्तिगत स्कूल प्रणाली में से प्रत्येक से बात करने में सक्षम थी।

प्रत्येक सिस्टम एक सरल HTTP GET का उपयोग करके एक दूसरे से जानकारी प्राप्त करेगा। यदि एक सिस्टम को किसी अन्य सिस्टम में कुछ जोड़ने की आवश्यकता होती है, तो वह HTTP POST का उपयोग करेगा। यदि कोई सिस्टम किसी अन्य सिस्टम में कुछ अपडेट करना चाहता है, तो वह HTTP PUT का उपयोग करता है। केवल यह जानने के लिए कि डेटा कैसा दिखना चाहिए।

— marcgg
स्रोत

6

पत्नी: क्या यह एक और रोबोट की बात है?

— तोबू

4

यह एक अच्छा पाठ है, लेकिन इसने ऐसा कोई उदाहरण नहीं दिया कि हर चीज के लिए GET और POST का उपयोग करना क्यों बुरा होगा।

— दिमित्री सी।

9

इसलिए मैं यह जानने की कोशिश करता हूं कि यह बेहतर क्यों है :-)

— दिमित्री C.

7

लेखन को नीचे ले जाया गया है।

— सर्फ

2

@ सुरफेन वेनबैकमैचिन

— felickz

5

मैं हर किसी को सुझाव दूंगा, जो इस प्रश्न का उत्तर ढूंढ रहा है, इस "स्लाइड शो" से गुजरें ।

मैं समझ नहीं पाया कि REST क्या है और यह इतना अच्छा क्यों है, इसके पेशेवरों और विपक्ष, SOAP से मतभेद - लेकिन यह स्लाइड शो इतना शानदार और समझने में आसान था, इसलिए यह मेरे लिए पहले की तुलना में अब बहुत अधिक स्पष्ट है।

— DreifGenov
स्रोत

3

भंडारित करता है।

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

— माइक
स्रोत

3

क्या आप एक उदाहरण दे सकते हैं कि कैश्ड क्या हो सकता है और कैशिंग गैर-रेस्ट समाधान के साथ क्यों नहीं होगा?

— दिमित्री सी।

2

@Dimitri C .: एक लिंक wikipedia.org/article?id=19 एक प्रॉक्सी द्वारा कैश नहीं किया जाएगा, क्योंकि यह यूआरएल में दिए गए मापदंडों की अनदेखी करता है। दूसरी तरफ एक लिंक wikipedia.org/REST को कैश किया जाएगा, समझा जाएगा?

— वी.पी.

6

यदि कैशिंग आरईएसटी का मुख्य लाभ था, तो मैं आपको आश्वासन दे सकता हूं कि मैंने पिछले दो वर्षों में रेस्टफुल सेवाओं के निर्माण में खर्च नहीं किया होगा।

— डारेल मिलर

डारेल, आप ऐसी प्रणालियों का निर्माण कर सकते हैं जो वितरण के पैमाने पर हैं जिसमें ढीली युग्मन का सबसे अधिक महत्व है (यह जानने के लिए रुचि है कि ये किस प्रकार के सिस्टम हैं), लेकिन अधिकांश लोग नहीं हैं - या वे प्रौद्योगिकियों का उपयोग कर रहे हैं (अर्थात ब्राउज़र और HTML) जिसमें बड़ी संख्या में उनके लिए कड़ी मेहनत की जाती है।

— माइक

1

तो क्यों नहीं बस का उपयोग करें GET /get_article/19/और POST /update_articleअगर कैशिंग आपकी चिंता है। तुम अब भी बस के साथ सब कुछ कर सकते हैं GETऔर POSTऔर मेरा मानना है कि REST"उपयोग का मतलब है GET, POST, PUTऔर DELETEकेवल।" और न केवल "क्वेरी स्ट्रिंग का उपयोग न करें।" इसलिए मैंने जो सुझाव दिया वह नहीं होगा REST। फिर से, कोई भी वास्तव में सहमत नहीं हो सकता REST है इसलिए मैं इसे "वेब 2.0" के साथ एक बाल्टी में डाल रहा हूं।

— टिम्मम्म

3

यह फील्डिंग शोध प्रबंध में लिखा गया है । लेकिन अगर आप बहुत कुछ नहीं पढ़ना चाहते हैं:

स्केलेबिलिटी में वृद्धि (स्टेटलेस, कैश और लेयर्ड सिस्टम की कमी के कारण)
ग्राहक और सर्वर को डिकॉय किया गया (स्टेटलेस और यूनिफ़ॉर्म इंटरफेस की कमी के कारण)
- पुन: प्रयोज्य ग्राहक (क्लाइंट सामान्य REST ब्राउज़रों और RDF शब्दार्थों का उपयोग करके यह तय कर सकता है कि कौन सी लिंक का अनुसरण करें और कैसे परिणाम प्रदर्शित करें)
- गैर ब्रेकिंग क्लाइंट (क्लाइंट केवल विशिष्ट विशिष्ट शब्दार्थ परिवर्तन द्वारा ही विराम देते हैं, क्योंकि वे कुछ एपीआई विशिष्ट ज्ञान के बजाय शब्दार्थ का उपयोग करते हैं)

— inf3rno
स्रोत

0

हर "संसाधन" को एक आईडी दें
चीजों को आपस में जोड़ते हैं
मानक विधियों का उपयोग करें
एकाधिक अभ्यावेदन के साथ संसाधन
सांविधिक रूप से संवाद करें

केवल POST और GET के साथ सब कुछ करना संभव है? हां, क्या यह सबसे अच्छा तरीका है? क्यों नहीं? क्योंकि हमारे पास मानक तरीके हैं। यदि आप फिर से सोचते हैं, तो केवल GET का उपयोग करके सब कुछ करना संभव होगा .. तो हमें POST का उपयोग करने से क्यों परेशान होना चाहिए? मानकों के कारण!

उदाहरण के लिए, आज एक एमवीसी मॉडल के बारे में सोचते हुए, आप अपने आवेदन को केवल विशिष्ट प्रकार की क्रियाओं जैसे POST, GET, PUT और DELETE पर प्रतिक्रिया देने के लिए सीमित कर सकते हैं। यहां तक कि अगर हुड के नीचे सब कुछ POST और GET के लिए उत्सर्जित होता है, तो अलग-अलग क्रियाओं के लिए अलग-अलग क्रियाएं करने का कोई मतलब नहीं है?

— उपाध्यक्ष।
स्रोत

1

"यह केवल GET का उपयोग करके सब कुछ करना संभव होगा": मैंने पहले ही सिल्वरलाइट में HTTP GET के साथ कुछ प्रयोग किए। मेरा निष्कर्ष यह था कि GET संदेश आकार में काफी सीमित होते हैं, जबकि POST संदेश बड़े (फिर से: सिल्वरलाइट सेटिंग में) हो सकते हैं। इसलिए मैं सब कुछ के लिए HTTP POST का उपयोग करना चुनूंगा! :-)

— दिमित्री सी।

दोनों समाधान मानकों के विरुद्ध हैं। POST के माध्यम से सब कुछ अच्छा नहीं है, विशेष रूप से प्रश्नों के लिए। ध्यान दें कि पिछले वर्षों में सभी खोज इंजन जो GET के रूप में काम करते थे अब GET के रूप में काम करते हैं। क्यों? क्योंकि "पाने" की विधि में यह क्षमता होती है कि वह स्पिडर्ड ...

— वी.पी.

0

REST में डिस्कवरी बहुत आसान है। हमारे पास WADL दस्तावेज़ (पारंपरिक वेब सेवाओं में WSDL के समान) हैं जो आपको दुनिया में अपनी सेवा का विज्ञापन करने में मदद करेंगे। आप UDDI खोजों का भी उपयोग कर सकते हैं। पारंपरिक HTTP POST और GET से लोग आपके कॉल करने के लिए आपके संदेश अनुरोध और प्रतिक्रिया स्कीमा को नहीं जान सकते हैं।

— बालाजी
स्रोत

1

WADL दस्तावेज़ के साथ एक RESTful वेब सेवा का वर्णन करना REST के मुख्य लाभों में से एक को हरा देता है, विशेष रूप से, हाइपरमीडिया से प्राप्त सभी लाभ।

— थॉमस एलिसिंगर

@ThomasEizinger क्या वाकई WADL इतनी बुरी चीज है? वर्तमान में हम एक अन्य कंपनी के साथ काम कर रहे हैं जिसने शीर्ष पर एक WADL प्रदान नहीं किया है जो हमारे अनुरोध को शामिल करने के आधार पर json-ऑब्जेक्ट देता है। मुझे लगता है कि WADL सोच को स्पष्ट करने के लिए सहायक होगा।

— सर्फ करें

WADL एक HTTP एपीआई का वर्णन करने में एक महान काम करता है, क्योंकि यह वही है जिसे इसके लिए डिज़ाइन किया गया था। इस कंपनी द्वारा प्रदान की जाने वाली सेवा के आधार पर, WADL एक अच्छा विचार हो सकता है या नहीं भी हो सकता है। यदि सेवा हाइपरमीडिया का लाभ नहीं लेती है और सिर्फ JSON में कुछ ऑब्जेक्ट्स को क्रमबद्ध करती है, तो उन्हें अपनी सेवा कैसे काम करती है और इसकी क्या अपेक्षा है / रिटर्न के बारे में प्रलेखन (WADL, स्वैगर, आदि) प्रदान करना चाहिए। WADL प्रति se बिल्कुल खराब नहीं है, यह सिर्फ (सही मायने में) RESTful webservice के लिए सही उपकरण नहीं है।

— थॉमस एलिज़र

0

एक लाभ यह है कि, हम गैर-क्रमिक रूप से XML दस्तावेज़ों और विभिन्न स्रोतों जैसे कि इनपुटस्ट्रीम ऑब्जेक्ट, एक URL, एक DOM नोड ... से अनमार्ट XML डेटा की प्रक्रिया कर सकते हैं।

— विजय जन
स्रोत

0

@Timmmm, आपके संपादन के बारे में:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

यह नाटकीय रूप से कॉल की संख्या को कम करेगा

और कुछ भी नहीं आप एक सर्वर है कि अपने ग्राहकों को चाहते हो सकता है क्षेत्र मान निरूपित करने के लिए HTTP मापदंडों को स्वीकार करने से रोकता है ...

लेकिन यह एक विस्तार है।

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

अपनी टिप्पणी के लिए के रूप में

"सभी क्रियाएं आसानी से CRUD में नहीं बनती (बनाएं, पढ़ें / पुनः प्राप्त करें, अपडेट करें, हटाएं)।"

: RDBMS एक CRUD दृष्टिकोण, (SELECT / INSERT / DELETE / UPDATE) का उपयोग करता है, और डेटा मॉडल का प्रतिनिधित्व करने और कार्य करने का एक तरीका हमेशा होता है।

अपनी सजा के बारे में

"आप ऑब्जेक्ट प्रकार के संसाधनों के साथ भी व्यवहार नहीं कर सकते हैं"

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

— क्वेल क्यूं
स्रोत

-1

खोज इंजन द्वारा क्वेरी-स्ट्रिंग्स को अनदेखा किया जा सकता है।

— wisty
स्रोत

8

क्वेरी स्ट्रिंग का उपयोग करना पूरी तरह से RESTful है।

— एमिल इवानोव

दिमित्री, कुछ खोज इंजन गतिशील लिंक की उपेक्षा करते हैं। इतना अधिक नहीं है, लेकिन यह अभी भी पर आधारित है। यदि आप एक छोटी सी साइट चलाते हैं, तो हो सकता है कि googlebot आपके सभी पृष्ठों को अनुक्रमित न करे यदि उनके पास पथ में एक प्रश्न चिह्न है।

— १२:०२

3

... जो सिर्फ स्पष्ट रूप से झूठी गूगल है, जब आप का उल्लेख: googlewebmastercentral.blogspot.com/2008/09/...

— Boldewyn

-1 के लिए क्वेरी-स्ट्रिंग्स को खोज इंजन द्वारा अनदेखा नहीं किया जाता है। webmasters.googleblog.com/2008/09/…

— कांस्य पुरुष

गैर-आरईएसटी HTTP के बजाय आरईएसटी का उपयोग करने का क्या फायदा है?

1. सरल

2. कैशिंग

3. संगठन

4. प्रयोग करने में आसान / कार्यान्वित

खोजे जाने

अन्य उपकरणों के साथ संगतता

मानकीकृत क्रिया नाम

मानकीकृत स्थिति

उदाहरण

थर्ड पार्टी एडिट