यदि REST अनुप्रयोगों को स्टेटलेस माना जाता है, तो आप सत्रों का प्रबंधन कैसे करते हैं?


536

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

विकिपीडिया से:

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

क्या वे सिर्फ सत्र / आवेदन स्तर डेटा स्टोर का उपयोग नहीं कर रहे हैं ???

मुझे लगता है कि REST का एक लक्ष्य URI पहुंच को सुसंगत और उपलब्ध बनाना है, उदाहरण के लिए, पोस्ट के अंदर पेजिंग अनुरोधों को छिपाने के बजाय, अनुरोध के पृष्ठ संख्या को GET URI का एक हिस्सा बनाना। मेरी समझ मे आ रहा है। लेकिन ऐसा लगता है कि यह बस ओवरबोर्ड कह रहा है कि प्रति ग्राहक डेटा (सत्र डेटा) को कभी भी सर्वर साइड संग्रहीत नहीं किया जाना चाहिए।

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

क्या मुझे नई संदेश सूची का अनुरोध करने पर हर बार ब्लॉक करने के लिए संदेश भेजने वालों की पूरी सूची भेजनी होगी? मेरे लिए उपयुक्त संदेश सूची पहले स्थान पर सार्वजनिक रूप से उपलब्ध संसाधन नहीं होनी चाहिए / नहीं होनी चाहिए।

फिर, बस इसे समझने की कोशिश कर रहा हूं। कोई कृपया स्पष्ट करें।


अपडेट करें:

मुझे एक स्टैक ओवरफ्लो प्रश्न मिला है जिसका एक उत्तर है जो मुझे वहां बिल्कुल नहीं मिलता है: रीस्ट में राज्य का प्रबंधन कैसे करें जो कहता है कि क्लाइंट स्टेट जो कि महत्वपूर्ण है, सभी को हर अनुरोध पर स्थानांतरित किया जाना चाहिए .... Ugg .. बहुत ओवरहेड की तरह लगता है ... क्या यह सही है ??


2
@ S.Lott: मुझे नहीं लगता कि यह जानबूझकर भ्रामक है। मुझे लगता है कि भ्रामक शब्दावली के कारण यह गलतफहमी है।
JUST MY सही ओपिनियन

2
@ मेरा सही चुनाव: दिलचस्प अनुमान। मैं इस तरह की बात पर विश्वास नहीं कर सकता था, खुद, क्योंकि यह स्पष्ट है कि "स्टेटलेस" का मतलब है कि आरईएसटी प्रोटोकॉल खुद ही स्टेटलेस है; जो कि अंतर्निहित एप्लिकेशन स्थिति के बारे में कुछ नहीं कहता है और इसे PUT, POST और DELETE अनुरोधों के साथ अपडेट करता है।
एस.लॉट

@ S.Lott: HTTP प्रोटोकॉल स्वयं ही स्टेटलेस है। नीचे हमने जो चर्चा की है, उसमें REST वेबसर्वर हैंडल सेशन स्टेट (DB की तरह चीजों में अन्य प्रकार के राज्य के विपरीत) न होते हुए आपके ऐप को बनाने का एक दृष्टिकोण है। मुझे यह भी नहीं लगा कि REST एक प्रोटोकॉल था , लेकिन HTTP प्रोटोकॉल का उपयोग करने के तरीके पर एक दृष्टिकोण। मुझे लगा कि आप लोगों ने इसे साफ़ कर दिया है कि ग्राहक पक्ष के सभी ग्राहक सत्रों के डेटा को स्टोर करके, और यूआरआई को जहाँ तक नहीं होना चाहिए, को छोड़ कर, यूपीआई एक्सेस के रूप में अपने आवेदन को बनाने के बारे में था। शायद नहीं ...:
ज़क

1
"शायद नहीं .." इसका क्या मतलब है? क्या आपके पास एक नया सवाल है? इसके लिए SO की खोज करने के लिए स्वतंत्र महसूस करें। यदि यह यहां मौजूद नहीं है, तो इसे पूछें।
S.Lott

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

जवाबों:


339

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

वास्तव में दो प्रकार के राज्य होते हैं। एप्लिकेशन स्टेट जो क्लाइंट और रिसोर्स स्टेट पर रहता है जो सर्वर पर रहता है।

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

संसाधन स्थिति प्रत्येक क्लाइंट के लिए समान है, और सर्वर पर इसका उचित स्थान है। जब आप किसी चित्र को सर्वर पर अपलोड करते हैं, तो आप एक नया संसाधन बनाते हैं: नई तस्वीर का अपना URI होता है और भविष्य के अनुरोधों का लक्ष्य हो सकता है। आप HTTP के माध्यम से इस संसाधन को ला सकते हैं, संशोधित कर सकते हैं और हटा सकते हैं।

आशा है कि यह इस बात में अंतर करने में मदद करता है कि स्टेटलेसनेस और विभिन्न राज्यों का क्या मतलब है।


4
क्या इसका मतलब यह है कि हर बार अनुरोध भेजे जाने पर ग्राहक को अपने उपयोगकर्ता / पासवर्ड को प्रमाणित करने के लिए भेजना चाहिए? क्योंकि मुझे लगता है कि एक सत्र को संग्रहीत करना, भले ही यह सभी सर्वरों के बीच एक साझा नो-एसक्यूएल डीबी पर हो, स्टेटलेस नहीं है, या है?
कार्लोस नवारो एस्टियासारन

1
@ कार्लोसनवरोअस्तियासारन स्टेटलेस प्रमाणीकरण से निपटने के लिए विभिन्न तकनीकें हैं। उदाहरण के लिए Google JWT।
जियोसाइडिक

1
@geoidesic: "क्योंकि JSON वेब टोकन स्टेटलेस होते हैं, इसलिए सर्वर स्टेट को स्टोर किए बिना उन्हें अमान्य करने का कोई तरीका नहीं है, इस प्रकार स्टेटलेस टोकन का लाभ हराया जा सकता है।" WIkipedia
ulatekh

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

@AndrewTFinnell: यदि आपको सर्वर पर स्वीकृत आईडी को स्टोर करना है, तो इसे उन सभी संभावित सर्वर पर स्टोर करना होगा, जो REST लॉगिन को प्रोसेस कर सकते हैं, जिसमें एक बड़े पैमाने पर समानांतर वेब-सर्वर आर्किटेक्चर में बहुत सारे सर्वर स्टेट शामिल हो सकते हैं।
ulatekh

491

मौलिक स्पष्टीकरण है:

सर्वर पर कोई क्लाइंट सत्र स्थिति नहीं।

राज्यविहीन तक इसका मतलब है कि सर्वर के बारे में किसी भी राज्य की दुकान नहीं है ग्राहक सत्र सर्वर साइड पर।

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

यह अन्य सेवाओं को नहीं रोकता है जो वेब सर्वर खरीदारी कार्ट जैसी व्यावसायिक वस्तुओं के बारे में राज्य को बनाए रखने से बात करता है, न कि ग्राहक के वर्तमान एप्लिकेशन / सत्र राज्य के बारे में।

ग्राहक के आवेदन राज्य सर्वर पर कभी नहीं संग्रहित किया जाना चाहिए, लेकिन से चारों ओर से पारित कर दिया ग्राहक हर जगह इसकी आवश्यकता है कि करने के लिए।

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

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

यहां तक ​​कि एक सेवा के लिए, जो आपको लगता है कि केवल 10 के हजारों समवर्ती उपयोगकर्ताओं की आवश्यकता होगी , आपको अभी भी अपनी सेवा को निष्क्रिय बनाना चाहिए। हजारों लोग अभी भी हज़ारों हैं और इसके साथ जुड़े समय और स्थान की लागत भी होगी।

स्टेटलेस है कि कैसे HTTP प्रोटोकॉल और वेब को सामान्य रूप से संचालित करने के लिए डिज़ाइन किया गया था और एक समग्र सरल कार्यान्वयन है और सत्र राज्य का एक गुच्छा बनाए रखने के लिए आपके पास सर्वर साइड लॉजिक का एक गुच्छा के बजाय एक एकल कोड पथ है।

कुछ बहुत ही बुनियादी कार्यान्वयन सिद्धांत हैं:

ये ऐसे सिद्धांत हैं जो कार्यान्वयन नहीं हैं, आप इन सिद्धांतों को कैसे पूरा कर सकते हैं।

सारांश में, पाँच प्रमुख सिद्धांत हैं:

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

REST शोध प्रबंध में प्रमाणीकरण या प्राधिकरण के बारे में कुछ भी नहीं है ।

क्योंकि एक अनुरोध को प्रमाणित करने से अलग कुछ भी नहीं है जो कि ऐसा नहीं है। प्रमाणीकरण Restful चर्चा के लिए अप्रासंगिक है।

अपनी विशेष आवश्यकताओं के लिए एक स्टेटलेस एप्लिकेशन बनाने का तरीका बताते हुए, स्टैकऑवरफ्लो के लिए बहुत व्यापक है।

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

इस वसीयत पर मदद / जानकारी मांगने वाले कमेंट / झंडे चाहिए जो किसी भी लम्बे समय के लिए न हों


22
यह एक बहुत ही बोल्ड स्टेटमेंट की तरह लगता है कि यह लाखों उपयोगकर्ताओं को स्केल करने का एकमात्र तरीका है। सर्वर साइड सेशन सिर्फ दूसरी सेवा क्यों नहीं हो सकती?
जक

27
@Zak: क्योंकि लाखों सत्र लाखों सत्र हैं। मुद्दा यह है कि इस सभी सत्र प्रबंधन के ओवरहेड से बचने के लिए।
S.Lott

91
यह बोल्डनेस नहीं है यह अनुभव है

21
मेरे जवाब में कुछ भी हर अनुरोध पर डेटाबेस एक्सेस के आधार पर एक समाधान का अर्थ नहीं है, अगर आपको लगता है कि यह करता है, तो यह उस पैमाने पर प्रमाणीकरण और प्राधिकरण को समझने के लिए आपके हिस्से पर विफल है। प्रमाणीकरण को राज्य में निहित किया जा सकता है, क्या आपको लगता है कि फेसबुक अपने REST API के हर अनुरोध पर "डेटाबेस एक्सेस" करता है? या उस बात के लिए Google? संकेत: नहीं

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

76

क्या वे सिर्फ सत्र / आवेदन स्तर डेटा स्टोर का उपयोग नहीं कर रहे हैं ???

नहीं, वे यह नहीं कह रहे हैं कि एक तुच्छ तरीके से।

वे कह रहे हैं कि "सत्र" को परिभाषित न करें। लॉगिन न करें। लॉगआउट न करें। अनुरोध के साथ क्रेडेंशियल प्रदान करें। प्रत्येक अनुरोध अकेला खड़ा है।

आपके पास अभी भी डेटा स्टोर हैं। आपके पास अभी भी प्रमाणीकरण और प्राधिकरण है। आप सिर्फ सत्रों की स्थापना और सत्र की स्थिति बनाए रखने के लिए समय बर्बाद नहीं करते हैं।

मुद्दा यह है कि प्रत्येक अनुरोध (ए) पूरी तरह से अकेले खड़ा है और (बी) को बिना किसी वास्तविक काम के एक विशाल समानांतर सर्वर फ़ार्म पर तुच्छ रूप से खेती की जा सकती है। अपाचे या स्क्विड नेत्रहीन और सफलतापूर्वक चारों ओर Restful अनुरोध पारित कर सकते हैं।

क्या होगा यदि मेरे पास संदेशों की कतार है, और मेरा उपयोगकर्ता संदेशों को पढ़ना चाहता है, लेकिन जैसा कि उसने उन्हें पढ़ा था, अपने सत्र की अवधि के लिए आने वाले कुछ प्रेषकों के संदेशों को अवरुद्ध करना चाहता था?

यदि उपयोगकर्ता फ़िल्टर चाहता है, तो बस प्रत्येक अनुरोध पर फ़िल्टर प्रदान करें।

क्या यह समझ में नहीं आएगा ... क्या सर्वर में केवल संदेश (या संदेश आईडी) हैं जो उपयोगकर्ता द्वारा अवरुद्ध नहीं किए गए थे?

हाँ। RESTful URI अनुरोध में फ़िल्टर प्रदान करें।

क्या मुझे नई संदेश सूची का अनुरोध करने पर हर बार ब्लॉक करने के लिए संदेश भेजने वालों की पूरी सूची भेजनी होगी?

हाँ। यह "संदेश भेजने वालों की सूची को अवरुद्ध करने के लिए" कितना बड़ा हो सकता है? पीके की एक छोटी सूची?

एक GET अनुरोध बहुत बड़ा हो सकता है। यदि आवश्यक हो, तो आप एक POST अनुरोध की कोशिश कर सकते हैं, भले ही यह एक तरह की क्वेरी की तरह लग रहा हो।


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

2
@BeniRose हम स्थानीय स्टोर में एक टोकन स्टोर नहीं कर सकते हैं और उस टोकन का उपयोग उन अनुरोधों में कर सकते हैं जो उपयोगकर्ता की विशिष्ट पहचान करेंगे?
निखिल साहू

1
लोकलस्टोरेज की सुरक्षा संबंधी बहुत सारी चिंताएँ हैं जो मुझे समझ में आती हैं। लेकिन क्लाइंट साइड सेशन के साथ अन्य चिंताओं का एक गुच्छा भी है, जैसे टोकन को अमान्य करना, उपयोगकर्ता को लॉग आउट करना, आदि
BeniRose

3
आप JWT का उपयोग करते हैं, जिस पर हस्ताक्षर हैं, हस्ताक्षर सत्यापन तेज़ है ताकि आप उस राज्य की वैधता की जांच कर सकें।
आर्किमिडीज ट्राजनो

36

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

जैसे ही आप एक विशिष्ट क्लाइंट के इंटरैक्शन से संबंधित कुछ जानकारी का प्रबंधन करने के लिए सर्वर पर एक छोटी सी जिम्मेदारी डालते हैं, वह बोझ सर्वर का उपभोग करने के लिए जल्दी से बढ़ सकता है।

यह एक व्यापार बंद है।


32

उपयोगकर्ता अनुप्रयोग राज्य प्रबंधन का ऐतिहासिक दृष्टिकोण

पारंपरिक अर्थों में सत्र सर्वर के अंदर अनुप्रयोग में उपयोगकर्ता की स्थिति को बनाए रखते हैं। यह प्रवाह में वर्तमान पृष्ठ हो सकता है या जो पहले दर्ज किया गया है, लेकिन मुख्य डेटाबेस के लिए अभी तक कायम नहीं है।

इस आवश्यकता का कारण क्लाइंट को विशिष्ट (यानी ब्राउज़र विशिष्ट) एप्लिकेशन या प्लग-इन किए बिना राज्य को प्रभावी ढंग से बनाए रखने के लिए मानकों की कमी थी।

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

REST सेवाओं का सामान्य उपयोग

REST सेवाओं को आम तौर पर कहा जाता है जब कोई लेनदेन होता है जिसे निष्पादित करने की आवश्यकता होती है या यदि उसे डेटा पुनर्प्राप्त करने की आवश्यकता होती है।

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

प्रमाणित कर रहा है

सर्वर के किसी भी अनुरोध के लिए, अनुरोध के भाग में प्राधिकरण टोकन होना चाहिए। इसे कैसे लागू किया जाता है यह एप्लिकेशन विशिष्ट है, लेकिन सामान्य तौर पर या तो ए हैBASIC याCERTIFICATE प्रमाणीकरण के रूप।

प्रपत्र आधारित प्रमाणीकरण REST सेवाओं द्वारा उपयोग नहीं किया जाता है। हालाँकि, जैसा कि REST सेवाओं के ऊपर उल्लेख किया गया है, इसका अर्थ उपयोगकर्ता द्वारा नहीं, बल्कि एप्लिकेशन द्वारा बुलाया जाना है। आवेदन को प्रमाणीकरण टोकन प्राप्त करने का प्रबंधन करने की आवश्यकता है। मेरे मामले में मैंने स्वचालित रूप से परीक्षण के लिए प्रमाणीकरण और सरल HTTP प्रमाणीकरण के लिए Google से कनेक्ट करने के लिए OAuth 2.0 के साथ JASPIC के साथ कुकीज़ का उपयोग किया । मैंने JASPIC के माध्यम से HTTP हेडर प्रमाणीकरण का भी उपयोग किया स्थानीय परीक्षण के लिए के (हालांकि साइटमिंडर में भी यही दृष्टिकोण किया जा सकता है)

उन उदाहरणों के अनुसार, प्रमाणीकरण क्लाइंट पक्ष पर प्रबंधित किया जाता है (हालांकि साइटमाइंडर या Google प्रमाणीकरण सत्र को उनके अंत में संग्रहीत करेगा), उस राज्य के बारे में कुछ भी नहीं किया जा सकता है, लेकिन यह REST सेवा एप्लिकेशन का हिस्सा नहीं है।

पुनर्प्राप्ति अनुरोध

आरईएसटी में पुनर्प्राप्ति अनुरोध ऐसे GETसंचालन हैं जहां एक विशिष्ट संसाधन का अनुरोध किया जाता है और यह देखने योग्य है। सर्वर सत्रों की कोई आवश्यकता नहीं है क्योंकि अनुरोध में डेटा को पुनः प्राप्त करने के लिए आवश्यक सब कुछ है: प्रमाणीकरण और यूआरआई।

लेनदेन की स्क्रिप्ट

जैसा कि ऊपर उल्लेख किया गया है, क्लाइंट-साइड एप्लिकेशन स्वयं ही प्रमाणीकरण सेवाओं के साथ REST सेवाओं को कॉल करता है जो इसे क्लाइंट साइड पर भी प्रबंधित करता है।

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

यह POSTआमतौर पर एक अनुरोध के माध्यम से किया जाता है , लेकिन अन्य जैसे कि PUTइसका उपयोग भी किया जा सकता है।

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

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

मतदान

हालांकि REST का उपयोग मतदान के लिए भी किया जा सकता है, लेकिन मैं इसे तब तक अनुशंसित नहीं करूंगा जब तक आपको ब्राउज़र संगतता के कारण इसका उपयोग न करना पड़े। उसके लिए मैं WebSockets का उपयोग करूंगा, जिसे मैंने एक API अनुबंध के लिए भी डिज़ाइन किया था । पुराने ब्राउज़रों के लिए एक और विकल्प CometD है।


27

REST बहुत सार है। यह कुछ अच्छे, सरल, वास्तविक दुनिया उदाहरणों में मदद करता है।

उदाहरण के लिए सभी प्रमुख सोशल मीडिया ऐप्स - Tumblr, Instagram, Facebook और Twitter को लें। उन सभी के पास हमेशा के लिए स्क्रॉल करने का दृश्य होता है जहां आप नीचे स्क्रॉल करते हैं, जितनी अधिक सामग्री आप देखते हैं, आगे और पीछे समय में। हालाँकि, हमने उस क्षण का अनुभव किया है जहाँ आप खो गए हैं जहाँ आपको स्क्रॉल किया गया था, और ऐप आपको शीर्ष पर वापस लाता है। जैसे अगर आप ऐप छोड़ देते हैं, तो जब आप इसे फिर से खोलते हैं, तो आप फिर से शीर्ष पर वापस आ जाते हैं।

क्यों, इसका कारण यह है कि सर्वर ने आपके सत्र की स्थिति संग्रहीत नहीं की थी। अफसोस की बात है कि आपकी स्क्रॉल स्थिति केवल क्लाइंट पर रैम में संग्रहीत थी।

सौभाग्य से जब आप पुन: कनेक्ट करते हैं तो आपको वापस लॉग इन नहीं करना पड़ता है, लेकिन ऐसा केवल इसलिए होता है क्योंकि आपका क्लाइंट-साइड संग्रहित प्रमाणपत्र भी समाप्त नहीं हुआ है। एप्लिकेशन को हटाएं और पुनः इंस्टॉल करें, और आपको वापस लॉग इन करना होगा, क्योंकि सर्वर ने आपके आईपी पते को आपके सत्र के साथ नहीं जोड़ा था।

आपके पास सर्वर पर लॉगिन सत्र नहीं है, क्योंकि वे REST द्वारा पालन करते हैं।


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

लेकिन एक सेकंड के लिए वेब ब्राउज़र के बारे में बात करते हैं, क्योंकि इससे REST का एक और बड़ा फायदा सामने आता है, जिसके बारे में यहां कोई भी बात नहीं कर रहा है।

यदि सर्वर ने सत्र स्थिति को संग्रहीत करने का प्रयास किया है, तो प्रत्येक व्यक्तिगत ग्राहक की पहचान कैसे की जाती है?

यह उनके आईपी पते का उपयोग नहीं कर सका, क्योंकि कई लोग एक साझा रूटर पर उसी पते का उपयोग कर सकते हैं। तो कैसे, फिर?

यह कई कारणों से मैक पते का उपयोग नहीं कर सकता है, जिनमें से कम से कम नहीं है क्योंकि आप विभिन्न ब्राउज़रों और ऐप पर एक साथ कई अलग-अलग फेसबुक खातों में लॉग इन हो सकते हैं। एक ब्राउज़र आसानी से एक और एक होने का दिखावा कर सकता है, और मैक पते केवल स्पूफ करने के लिए आसान हैं।

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


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


जहां लोग भ्रमित हो जाते हैं, यह सोचकर कि "राज्य" एक डेटाबेस में संग्रहीत जानकारी की तरह है। नहीं, यह किसी भी जानकारी को संदर्भित करता है जिसे सर्वर के रैम में होना चाहिए जब आप इसका उपयोग कर रहे हों।


13

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

सर्वर पर राज्य का प्रबंधन करने का मतलब है कि आपके सर्वर को ठीक से पता है कि ग्राहक क्या कर रहा है (वह कौन सा पृष्ठ है जो आवेदन के किस भाग में दिखाई दे रहा है)। और यही आपको करना चाहिए।

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

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

साथ ही सर्वर पर कुछ संवेदनशील सत्र डेटा रखना सही तरीका होना चाहिए। आप अपनी खरीदारी कार्ट को रखने के लिए क्लाइंट पर भरोसा नहीं कर सकते हैं (उदाहरण के लिए) में "FreeGift "नाम का फ़ील्ड है। ऐसी जानकारी सर्वर पर रखी जानी चाहिए।

संतनू डे द्वारा उनके जवाब में दिया गया वीडियो लिंक मददगार है। यदि आपने नहीं देखा है तो इसे देखें।

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

अल्थोगेट सवाल कुछ साल पुराना है, मुझे उम्मीद है कि मेरा जवाब अभी भी मददगार होगा।


4
मैं आम तौर पर इस भावना से सहमत हूं, लेकिन यह दावा करने के लिए हाल ही में एक प्रवृत्ति है कि यहां तक ​​कि एक सत्र पहचानकर्ता को सर्वर पर संग्रहीत नहीं किया जाना चाहिए। मुझे अभी तक यह पता नहीं चल पाया है कि वैकल्पिक समाधान क्या है, JWT अच्छी तरह से टाल दिया गया है, लेकिन कुछ मुट्ठी भर गोचरों के
बेनिरोज़

11

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

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

हाँ, http प्रोटोकॉल अनिवार्य रूप से एक स्टेटलेस प्रोटोकॉल है लेकिन इसे स्टेटफुल बनाने के लिए हम HTTP कुकीज़ बनाते हैं। तो, डिफ़ॉल्ट रूप से SOAP है। लेकिन इसे राज्यवार बनाया जा सकता है, यह आपके द्वारा उपयोग किए जा रहे ढांचे पर निर्भर करता है।

HTTP स्टेटलेस है लेकिन फिर भी हम अलग-अलग सेशन ट्रैकिंग मैकेनिज्म का उपयोग करके अपने जावा एप्लिकेशन में सेशन को बनाए रख सकते हैं।

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

Http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap से लिया गया


11

कोई चम्मच नहीं है।

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

लॉगिन पर एक शब्द हर बार बहस

हर समय सत्र और लॉग न रखने का क्या मतलब है? कुछ का मतलब है "हर बार पासवर्ड भेजें", यह सिर्फ सादा मूर्खता है। कुछ लोग कहते हैं कि "नहीं, इसके बजाय एक टोकन भेजें " - लो और निहारना, PHP सत्र लगभग यही कर रहा है। यह एक सत्र आईडी भेजता है जो एक प्रकार का टोकन है और यह आपको हर बार u / pw को हल किए बिना अपने व्यक्तिगत सामान तक पहुंचने में मदद करता है। यह भी काफी विश्वसनीय और अच्छी तरह से परीक्षण किया गया है। और हां, सुविधाजनक, जो एक खामी में बदल सकता है, अगले पैराग्राफ को देखें।

पदचिह्न कम करें

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

एक साझा संग्रहण एक आवश्यक है। सर्वर को कम से कम यह जानने की जरूरत है कि किसी ने लॉग इन किया है या नहीं। (और यदि आप डेटाबेस को हर बार आपको यह तय करने की आवश्यकता होती है, तो आप व्यावहारिक रूप से बर्बाद हो जाते हैं।) साझा स्टोरेज को डेटाबेस की तुलना में बहुत तेज होना चाहिए। यह प्रलोभन लाता है: ठीक है, मेरे पास बहुत तेज भंडारण है, वहां सब कुछ क्यों नहीं? - और यही वह जगह है जहां चीजें दूसरे तरीके से खराब हो जाती हैं।

तो आप कह रहे हैं, न्यूनतम करने के लिए सत्र का भंडारण रखें?

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

फिर यह कैसे करना है?

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

सोचें और निर्णय लें, डिजाइन के रुझान को अपने लिए सोचने न दें।


1
"सोचें और निर्णय लें, डिज़ाइन रुझानों को आपके लिए सोचने न दें।" दुर्भाग्य से आजकल यह बहुत आम हो गया है कि केवल मूर्खतापूर्ण रुझान का पालन करें। कभी-कभी SO पढ़ने से आपको ट्रेंड के कारण सभी समान उत्तर मिलेंगे।
l00k

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

@dkellner मुझे वह हिस्सा समझ में नहीं आया: "सर्वर को कम से कम यह जानने की आवश्यकता है कि क्या किसी ने लॉग इन किया है या नहीं। (और यदि आप डेटाबेस को हर बार आपको यह तय करने की आवश्यकता होती है, तो आप व्यावहारिक रूप से परेशान हैं।)"। कहते हैं कि आप डेटाबेस में सत्र डेटा को PHP के साथ संग्रहीत करते हैं। लॉग इन बैड (डीओएमड एक मजबूत शब्द है) के लिए डीबी को क्यों उद्धृत किया जाता है क्योंकि वैसे भी पीएचपी सत्र आईडी के आधार पर संपूर्ण उपयोगकर्ता डेटा और अन्य सामान प्राप्त करने के लिए कई बाद के डीबी अनुरोध होंगे? दूसरे शब्दों में, किसी भी मामले में DB प्रश्न अपरिहार्य हैं। इसके अलावा, यदि आप एक PHP सत्र आईडी प्राप्त नहीं करते हैं, तो आप जानते हैं कि उपयोगकर्ता अप्राप्य है, क्वेरी करने की कोई आवश्यकता नहीं है।
user2923322

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

5

इस प्रस्तुति पर एक नजर।

http://youtu.be/MRxTP-rQ-S8

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


1
कृपया पढ़ें मैं एक अच्छा उत्तर कैसे लिखूं? अधिक प्रश्नों का उत्तर देने का प्रयास करने से पहले।

3

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

IMO, API को स्टेटलेस होना चाहिए जो वास्तव में जल्दी से स्केल करने की अनुमति देता है।


2

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

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


यदि आप प्रत्येक अनुरोध के साथ डेटा भेजते हैं, तो आप क्लाइंट पर क्रेडेंशियल्स कहाँ / कैसे संग्रहीत करते हैं ताकि उपयोगकर्ता को हर अनुरोध पर इसे फिर से दर्ज न करना पड़े?
अंबर

1

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

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

यदि RESTful API उपयोगकर्ता नाम और पासवर्ड को बदलने के लिए उपयोगकर्ता नाम और पासवर्ड की अपेक्षा करता है, तो भले ही किसी ने सत्र आईडी का उपयोग करके उपयोगकर्ता को प्रतिरूपित किया हो, हैकर वास्तविक उपयोगकर्ता को लॉक नहीं कर पाएगा।

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

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


इस बनाता है भावना
mestarted

0

पूरी अवधारणा अलग है ... यदि आपको RESTFul प्रोटोकॉल को लागू करने की कोशिश कर रहे हैं तो आपको सत्रों का प्रबंधन करने की आवश्यकता नहीं है। उस मामले में हर अनुरोध पर प्रमाणीकरण प्रक्रिया करना बेहतर होता है (जबकि प्रदर्शन के मामले में इसके लिए अतिरिक्त लागत है - हैशिंग पासवर्ड एक अच्छा उदाहरण होगा। बड़ी बात नहीं है ...)। यदि आप सत्र का उपयोग करते हैं - तो आप कई सर्वरों पर लोड कैसे वितरित कर सकते हैं? मुझे यकीन है कि RESTFul प्रोटोकॉल सत्र को समाप्त करने के लिए है - आपको वास्तव में उनकी आवश्यकता नहीं है ... इसलिए इसे "स्टेटलेस" कहा जाता है। सत्र केवल तब आवश्यक होते हैं जब आप किसी ग्राहक के लिए कुकी के अलावा किसी अन्य चीज को स्टोर नहीं कर सकते हैं, जब एक रीकेस्ट किया गया हो (उदाहरण के रूप में पुराना, गैर जावास्क्रिप्ट / एचटीएमएल 5-सपोर्टिंग ब्राउजर)। "पूर्ण विशेषताओं वाले" RESTFul क्लाइंट के मामले में यह आमतौर पर स्टोर करना सुरक्षित होता हैbase64(login:password) ग्राहक पक्ष में (स्मृति में) जब तक कि मूल्यांकन अभी भी भरा हुआ है - आवेदन का उपयोग केवल होस्ट तक पहुंचने के लिए किया जाता है और कुकी को तीसरे पक्ष की स्क्रिप्ट से समझौता नहीं किया जा सकता है ...

मैं RESTFul सेवियों के लिए कुकी प्रमाणीकरण को अक्षम करने की सिफारिश करूंगा ... मूल / डाइजेस्ट प्रामाणिक की जांच करें - जो RESTFul आधारित सेवाओं के लिए पर्याप्त होना चाहिए।


3
क्लाइंट पक्ष में a client side (in memory) सहेजने के लिए क्या और कैसे सुरक्षित है base64(login:password)?
आरएन कुशवाहा

1
कुछ भी "पूरी तरह से सुरक्षित" के रूप में परिभाषित नहीं किया गया है। हालांकि, आप एपीआई अनुरोध (बेसिक ऑथेंट) के लिए बेस 64 स्ट्रिंग को बचाने की तुलना में बेहतर सुरक्षा प्रदान करने के लिए OAuth2 का उपयोग करने पर विचार कर सकते हैं, यदि आप बेसिक नॉर्म्स पर चिपके रहते हैं, तो आप बेहतर सुरक्षा के लिए HTTPS का उपयोग कर सकते हैं।
felixwcf

3
आरएन कुशवाहा, यह वह सवाल है जिसका जवाब कोई नहीं देना चाहता है जब वे आपको सर्वर पर भंडारण सत्र बंद करने और ग्राहक में संग्रहीत करने के लिए कहते हैं।
बेनिरोज

0

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


0

यहां स्टेटलेस का मतलब है कि सर्वर की ओर से अनुरोध की स्थिति या मेटा डेटा का रखरखाव नहीं किया जाता है। सर्वर पर प्रत्येक अनुरोध या उपयोगकर्ता की स्थिति को बनाए रखने से, यह प्रदर्शन बाधाओं को जन्म देगा। सर्वर को केवल किसी विशिष्ट ऑपरेशन को करने के लिए आवश्यक विशेषताओं के साथ अनुरोध किया जाता है।

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

यह एप्लिकेशन में उपयोगकर्ता की स्थिति को बनाए या रख सकता है।

उम्मीद है की यह मदद करेगा!

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