क्या सर्वर-साइड सत्र REST का उल्लंघन करते हैं?

Question

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

[[] क्लाइंट से सर्वर के लिए ach अनुरोध में अनुरोध को समझने के लिए आवश्यक सभी जानकारी होनी चाहिए, और सर्वर पर किसी भी संग्रहीत संदर्भ का लाभ नहीं उठा सकता है।

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

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

एक सत्र की अवधारणा आम है - विशेष रूप से वेब डेवलपर्स के लिए - लेकिन क्या यह उपरोक्त परिभाषा के अनुसार RESTful है?

Comments

मैं कहूंगा कि उस परिभाषा के अनुसार व्यावहारिक रूप से कुछ भी आराम करने योग्य नहीं है, लेकिन यह परिभाषा यथोचित तार्किक कैसे है? एक "विश्रामपूर्ण" Google खोज की कल्पना करें- जहां आपको अपने लिए खोज करने के लिए Google को अनुरोध में इंटरनेट का एक सूचकांक प्रदान करना होगा। क्या? नहीं, यह कहना कि आपके पास दृढ़ता की दुकान नहीं हो सकती है और बेचैन होना यह कहना कठिन होगा कि बाकी इंटरफेस वास्तव में बेकार हैं। इसका मतलब यह नहीं है कि हम सभी को इन-मेमोरी सत्रों को बनाए रखना शुरू करना चाहिए और यह कहना चाहिए कि यह अभी भी अच्छा बाकी है ...

— जिमी हॉफ

मुझे लगता है कि यह ध्यान दिया जाना चाहिए कि अनुप्रयोग राज्य और संसाधन राज्य के बीच अंतर है (Google सूचकांक संसाधन राज्य होगा, और पूरी तरह से वैध है)। मुझे प्रश्न में और स्पष्ट करना चाहिए।

— मैट

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

— जिमी हॉफ

मैंने खुद इस बात पर आश्चर्य जताया है। चूँकि किसी ने कभी यह नहीं बताया कि मेरे आवेदन को एक "आरामदायक" स्टार चाहिए या तो मुझे इसकी चिंता नहीं करनी चाहिए।

— Psr

Answer 1

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

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

मेरा वर्तमान समाधान यूआई / एसीएल / जो भी आवश्यक वस्तु को एक अलग ऑब्जेक्ट में देखने के लिए आवश्यक है और उस ऑब्जेक्ट के लिए URL (संभवत: एक यूयूआईडी) को वापस करना है । मेरा मानना ​​है कि व्यू ऑब्जेक्ट को एक्सेस करना इस अर्थ में Restful माना जा सकता है कि इसके कब्जे में सभी को एक ही जानकारी / अनुभव मिलता है।

Comments

आप देख रहे हैं वस्तु उदाहरण इस पर एक और कोण है। साफ।

— मैट

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

— मैट

यदि आप कह रहे हैं कि wsj साइट एक नॉन-रेस्टफुल ऐप का एक उदाहरण है, तो मैं असहमत होऊंगा कि आपका उदाहरण दिखाता है। यदि WSJ साइट उदाहरण के लिए है जो आपकी बहन के क्लाइंट द्वारा उसे डेटा प्रस्तुत करने के लिए पूरी तरह से दिए गए डेटा पर निर्भर है, तो यह @Matt द्वारा दी गई परिभाषा, RESTful द्वारा है। हालांकि यह अस्थायी-इन-मेमोरी सत्र स्थिति पर निर्भर करता है, यह उस परिभाषा द्वारा होता है जिसे मैट ने रेस्टफुल नहीं दिया था। मैं इसे केवल इसलिए इंगित करता हूं क्योंकि मैट ने जो परिभाषा दी है वह कार्यान्वयन बारीकियों पर आधारित है जबकि REST खपत तकनीक द्वारा बेहतर परिभाषित है।

— जिमी हॉफ

@ जिमीहॉफ - रेस्ट की बाधाओं के बारे में मेरी समझ यह है कि यह स्टेटलेस है । यह मेरे लिए बहुत असंदिग्ध लगता है।

— पीटर रोवेल

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

— जिमी हॉफ

Answer 2

क्या सर्वर-साइड सत्र REST का उल्लंघन करते हैं?

वे निश्चित रूप से करते हैं! जब आप REST लागू करते हैं, तो कोई सर्वर-साइड सत्र नहीं होना चाहिए, अन्यथा आपके पास एक हाइब्रिड RPC / REST समाधान है।

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

Answer 3

संभवतः "सत्र डेटा" से आपका क्या अर्थ है, इस पर निर्भर करता है। क्या यह एक सटीक शब्द है?

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

अगर इस तरह के ऑपरेशन को नॉन-रेस्टफुल करार दिया जाता है तो मुझे बहुत आश्चर्य होगा। OAuth एक उदाहरण है।

मैं एक विशेषज्ञ नहीं हूँ और मैं यहाँ बहुत आश्वस्त नहीं हूँ; मैं सिर्फ अपनी अंतर्दृष्टि साझा कर रहा हूं उम्मीद है कि वे मददगार साबित होंगे।

Answer 4

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

Comments

यह जरूरी नहीं है कि उपयोगकर्ता एक ही चीज देखेंगे .. एक्सेस डिक्टेट कर सकता है कि किसी एक उपयोगकर्ता को कितना देखने को मिलता है।

— एरिक

@ एरिक लेकिन उपयोगकर्ता यह बताएंगे कि वे अनुरोध में कितना देखना चाहते हैं (स्वीकारकर्ता का उपयोग करना शामिल है), इसलिए पुकल के उत्तर सही हैं।

— जोहान

@ जोहान मैं विभिन्न उपयोगकर्ताओं के लिए एक ही समापन बिंदु से अलग-अलग डेटा लौटाता हूं। अन्यथा उपयोगकर्ता को प्रमाणित करने की क्या बात है।

— एरिक

@ एरिक मैं वह भी करूंगा। कोई भी कम मुझे विश्वास नहीं है कि प्रमाणीकरण संसाधन की स्थिति से बाहर है, इसलिए सख्ती से बोलें यदि दृश्य प्रामाणिक उपयोगकर्ता से प्रभावित है तो यह अब RESTful नहीं है। हो सकता है कि यदि आप चाहते थे कि आपका RESTful बिल्ला आपको संसाधन के कई "विचार" बनाने चाहिए, तो इस बात पर निर्भर करता है कि कौन पहुंच का अनुरोध कर रहा है, यह केवल कुछ विचारों तक पहुंच को अधिकृत करता है। तो सार्वजनिक / USERPROFILES पर एक्सेस प्राप्त कर / {userID} / publicview और उपयोगकर्ता पहुँच / USERPROFILES / {userID} / fullprofile और अधिकृत मित्र प्राप्त करने के लिए उपयोग कर सकते / USERPROFILES / {userID} / friendsview जाता

— जोहान

Answer 5

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

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

इसलिए जब यह आधिकारिक तौर पर REST की परिभाषा का हिस्सा है, तो यह इतना उपयोगी है कि Restful अनुप्रयोगों को देखना दुर्लभ है जो सत्र के माध्यम से राज्य का उपयोग नहीं करते हैं।

Comments

मैं असहमत हूं। आपके पास एक शॉपिंग साइट है जो आपको ब्रांड, रंग और आकार के आधार पर फ़िल्टर करने देती है। पारंपरिक वेब 1.0 वेबसाइटें कुछ चेकबॉक्स, सर्वर साइड सत्र और POST के साथ इसे संभालेंगी। यदि मैं example.org/shirts का लिंक साझा करना चाहता हूं, तो लोग यह नहीं देखेंगे कि मैंने मीडियम, ब्लैक और रूट्स का चयन किया है। (यह भी कारण है कि जब आप वापस क्लिक करते हैं तो आप "आप डेटा को पुनः लोड कर रहे हैं" संदेश भेजते हैं।) लेकिन अगर मैं लिंक को साझा करता हूं (जैसे) example.org/shirts/medium-black-roots, तो सभी का समान प्रतिनिधित्व है। सभी आवश्यक राज्य जानकारी URL में है (या यदि आवश्यक हो तो POST निकाय, लेकिन आप इसे साझा नहीं कर सकते हैं)।

— जेसी बुकानन

... बाकी सब कुछ के लिए एक फिट नहीं हो सकता है। क्या आपका काल्पनिक अनुप्रयोग संसाधन उन्मुख (एक शॉपिंग साइट निश्चित रूप से है!)। शायद यह आरआईए के लिए फिट नहीं हो सकता है, जिसमें बहुत सारे राज्य हैं, जो संसाधन उन्मुख नहीं है। मैं ईमानदार होने के लिए किसी भी अच्छे उदाहरण के बारे में नहीं सोच सकता।

— जेसी बुकानन

Answer 6

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