आरईएसटी के बारे में बहुत भ्रम मौजूद है क्योंकि बहुत से लोग आरईएसटी बाधाओं के बारे में सुनते हैं और सोचते हैं कि वे ऐसे नियम हैं जो वास्तुकला का पालन करने के अलावा किसी भी कारण के लिए लागू नहीं हैं।
असली सवाल यह पूछना चाहिए कि क्यों स्टेटलेस बाधा आरईएसटी में मौजूद है, और इसके बाद से आपको क्या फायदे मिलते हैं। ध्यान रखें कि आरईएसटी एक वास्तुशिल्प शैली है जिसका उद्देश्य बड़े पैमाने पर वितरित सिस्टमों के दीर्घकालिक विकास के लिए है। आपको बस समस्याएं नहीं होंगी आरईएसटी को एक छोटे पैमाने पर आवेदन में हल करना है जहां एक डेटाबेस में आपकी सारी जानकारी होती है।
स्टेटलेस बाधा दृश्यता, विश्वसनीयता और स्केलेबिलिटी की संपत्ति को प्रेरित करती है। दृश्यता में सुधार हुआ है क्योंकि अनुरोध की पूर्ण प्रकृति को निर्धारित करने के लिए निगरानी प्रणाली को अनुरोध डेटाम से परे देखना नहीं है। विश्वसनीयता में सुधार हुआ है क्योंकि यह आंशिक विफलताओं से पुनर्प्राप्त करने का कार्य आसान बनाता है। स्केलेबिलिटी में सुधार हुआ है क्योंकि अनुरोधों के बीच स्टोर स्थिति नहीं होने से सर्वर घटक को मुफ्त संसाधनों की अनुमति मिलती है, और कार्यान्वयन को और आसान बनाता है क्योंकि सर्वर को अनुरोधों पर संसाधन उपयोग को प्रबंधित करने की आवश्यकता नहीं है।
तो, स्टेटलेस होने का मतलब क्लाइंट अनुरोध को संसाधित करने के लिए आवश्यक सभी जानकारी होनी चाहिए।
आपके लिए दृश्यता कितनी महत्वपूर्ण है? जब आप कुछ डिबग कर रहे हों, तो क्या आप ग्राहक अनुरोध से शॉपिंग कार्ट की संपूर्ण सामग्री को देखने में सक्षम होना चाहते हैं, या डेटाबेस से उस जानकारी को प्राप्त करने के साथ आप ठीक हैं?
विश्वसनीयता कितनी महत्वपूर्ण है? क्या आपके पास कई सर्वर और डेटाबेस के साथ एक बड़ी वितरित प्रणाली है, जहां यह महत्वपूर्ण है? यदि आपके पास एक बड़ी वितरित प्रणाली है जहां अनुरोध डेटा का जवाब देने वाले सटीक HTTP सर्वर के आधार पर शॉपिंग कार्ट की जानकारी अलग-अलग डेटाबेस में संग्रहीत की जा सकती है, यदि कोई सर्वर विफल रहता है तो उस समूह से केवल एक अन्य सर्वर अनुरोध को पूरा करने और सत्र समाप्त करने में सक्षम होगा , या किसी अन्य समूह का सर्वर क्लाइंट को सत्र को पुनरारंभ करने के लिए मजबूर करेगा। यदि सभी जानकारी अनुरोध में निहित है, तो कोई भी सर्वर इसे कर सकता है।
स्केलेबिलिटी कितनी महत्वपूर्ण है? यदि आपके पास एक वितरित सिस्टम है और आप एक ही डेटाबेस पर शॉपिंग कार्ट की जानकारी संग्रहीत कर रहे हैं, तो यह आपके सभी अनुरोधों के लिए एक फनल बन जाता है और आप स्केलेबिलिटी खो देते हैं। यदि आप इसे कई डेटाबेस पर संग्रहीत करते हैं, तो ऊपर बताए अनुसार आप विश्वसनीयता खो देते हैं।
तो, क्या आपके पास महत्वाकांक्षी दीर्घकालिक लक्ष्य हैं या आपका आवेदन इतना बड़ा होगा कि आप समस्याओं का सामना करेंगे REST प्रयासों को हल करने का प्रयास? यदि आपके पास हमेशा कुछ सर्वर और एक डेटाबेस होगा, और आप इसे प्रत्येक अनुरोध के लिए उपयोग करेंगे, तो इससे कोई फर्क नहीं पड़ता कि आप स्टेटलेस हैं या नहीं। आपके पास /shopping_cart संसाधन या कुछ ऐसा हो सकता है, POST अनुरोधों के साथ इसमें सामान जोड़ें, और जब आप पूरा कर लें तो इसे बंद या हटा दें।
यदि आपके पास एकाधिक डेटा में आपका डेटा शेड किया जाएगा, तो कई HTTP सर्वर अनुरोध, कैश सर्वर आदि का जवाब दे रहे हैं, और आप आवश्यकतानुसार नए सर्वर सेट करके क्षमता को गतिशील रूप से प्रावधान करने की क्षमता चाहते हैं और लोड कम होने पर उन्हें हटा देना, फिर पूर्ण स्टेटलेस जाएं और क्लाइंट के साथ शॉपिंग कार्ट छोड़ दें।
आपको रेफस्ट (हैलोबक्स कॉफी शॉप) के डिफैक्टो हैलो वर्ल्ड को देखना चाहिए। – Aron
आप इस अवधि की HTTP समझ में सत्र की स्थिति को भंग कर रहे हैं, और एक "सत्र" वैश्विक वस्तु जो सर्वर-साइड फ्रेमवर्क द्वारा प्रदान की गई एक आर्टिफैक्ट है। – guillaume31
मैं स्पष्टीकरण देना चाहता हूं ... शॉपिंग कार्ट, खरीदारी के पूरा होने के बाद डेटाबेस के लिए जारी रहेगा, प्रश्न मूल नहीं है। मेरा प्रश्न 4 वां आरईएसटी बाधा के संबंध में है जो स्टेटलेस को संचारित करता है या दूसरे शब्दों में सर्वर पर संग्रहीत कोई क्लाइंट सत्र डेटा नहीं होता है। और यह देखते हुए, शॉपिंग कार्ट स्टोर क्लाइंट कहां होगा? उस प्रश्न को उत्तर में नीचे स्पष्ट किया गया है। धन्यवाद। –