मैं इन दिनों token-based authentication को समझने की कोशिश कर रहा हूं, जो stateless authentication विधि होने का दावा करता है। और मैं stateless web application की अवधारणा से मुलाकात की।स्टेटलेस वेब एप्लिकेशन, एक शहरी किंवदंती?
नीचे कुछ धागे मैं के बारे में पढ़ा रहे हैं:
- Use Spring MVC for Stateless web application development (कोई अभी तक प्रतिक्रिया)
- Stateless Spring MVC
- How to make a java web application fully stateless
- How do I make my Web Application stateless yet still do something useful?
सबसे पहले, मैं इस पर रोमांचित थे विचार। लेकिन अधिक से अधिक मुझे लगता है कि stateless एक pseudo-proposition है।
उदाहरण के लिए, मान लीजिए कि हम प्रमाणीकरण के लिए क्लाइंट-संग्रहीत टोकन का उपयोग करते हैं, हम ऑनलाइन उपयोगकर्ताओं की एक सांख्यिकीय कैसे बना सकते हैं (मान लीजिए कि कोई लॉग नहीं है)? क्या हम डीबी में टोकन स्टोर करेंगे? इसका मतलब यह नहीं है कि हम सर्वर पर राज्य की जानकारी स्टोर करते हैं? और भी, क्या डीबी में नाम, आयु इत्यादि जैसी सादा उपयोगकर्ता जानकारी भी किसी प्रकार की राज्य जानकारी है?
मुझे लगता है कि यहाँ असली सवाल को वेब एप्लिकेशन राज्यविहीन बनाने के लिए है, लेकिन वेब अनुप्रयोग ठीक से राज्य की जानकारी ऐसी है कि वह scalability ख़तरे में डालना नहीं होगा संभाल करने के लिए नहीं है।
कि कैसे शब्द stateless व्याख्या करने के लिए पर निर्भर करता है:
- वेब एप्लिकेशन राज्य नहीं है।
- या वेब ऐप राज्य स्वयं स्टोर नहीं करता है।
मैं 2 पसंद करता हूं क्योंकि हमेशा कुछ inevitable global state (@ धोखे की टिप्पणी से उनके उत्तर में उद्धृत) हो सकते हैं। और इससे कोई फर्क नहीं पड़ता कि हम राज्य की जानकारी एचटीएमएल 5 वेब स्टोरेज, या HTTP हेडर, या छिपे हुए फॉर्म फ़ील्ड, या कुकी के रूप में संग्रहीत करते हैं, फिर भी राज्य मौजूद है। केवल यह कि सर्वर के अलावा कहीं और संग्रहीत है।
क्या मुझे कुछ अच्छा याद आ रहा है? क्या कोई इस पर कुछ प्रकाश डाल सकता है ताकि मुझे इस मानसिक संघर्ष से मुक्त किया जा सके?
जोड़ें 1
बस Leonard Richardson द्वारा पुस्तक RESTful Web Services बारे में पढ़ा। अध्याय 4 में, धारा Statelessness के अंत में, यह राज्य को Application State और Resource State में वर्गीकृत करता है। तो छवियों, आदि जैसे पहले उल्लेख की गई सादे उपयोगकर्ता जानकारी और डेटा को Resource State के रूप में वर्गीकृत किया जा सकता है। और stateless का संदर्भ Application State है। तो यह सर्वर पर resource state स्टोर करने के लिए स्टेटलेस के कोड को तोड़ नहीं देता है।
लेकिन पुस्तक में परिदृश्य का उल्लेख भी है जहां an application key is used to restrict how many times a user can invoke a web service. यह स्वीकार करता है कि ऐसी जानकारी क्लाइंट साइड पर संग्रहीत नहीं की जा सकती है। और सर्वर पक्ष पर इसे स्टोर करने के लिए स्टेटलेस के कोड को तोड़ता है और सत्र संबंध के मुद्दे को पेश करता है। यह दावा करता है कि स्टेटलेस सत्र एफ़िनिटी मुद्दे से बच सकता है लेकिन यह समझाता नहीं है कि कैसे।मैं वास्तव में नहीं देखता कि इस परिदृश्य को कैसे बेकार कर सकते हैं। कोई भी यहाँ कुछ प्रकाश डाल सकता है?
स्टेटलेस वेब एप्लिकेशन क्या है? आपको वह शब्द कहां से मिला? मुझे केवल स्टेटलेस कनेक्शन/प्रोटोकॉल पता है। – freakish
@freakish उत्तर के लिए धन्यवाद। मैंने इसे कई धागे से पढ़ा। मैंने यहां कुछ लोगों का सारांश दिया: http://stackoverflow.com/questions/34651801/how-to-make-stateless-web-applications- विशेष रूप से-with-spring-mvc – smwikipedia
मुझे लगता है कि यदि आप नुकसान की सूची लिखते हैं क्या आप परिभाषित करने में सक्षम होंगे कि कौन सा स्टेटलेस होना चाहिए, है ना? लेकिन वे नुकसान व्यक्तिपरक हैं, यही कारण है कि कोई स्पष्ट परिभाषा नहीं है। –