एक शोकहारा वास्तुकला

Question

स्टेटफुल क्लाइंट-सर्वर सॉफ्टवेयर विकास अनुभव के 15 साल (और यह निहित समस्याओं है) मैं अभी भी एक आरामदायक वास्तुकला में statelessness की अवधारणा को समझ कोशिश कर रहा हूँ के साथ में अद्वितीय बाधा।

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

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

यह बदले में मैंने जो कुछ सीखा है उसके खिलाफ चला जाता है और यह बिल्कुल स्वाभाविक नहीं लगता है। कृपया मुझे प्रबुद्ध ...

Answer 1

मुझे कोई कारण नहीं वापस नहीं करने के लिए उपयुक्त HTTP code देखें: 409 विरोधाभास। इसे आपके डेटाबेस से त्रुटियां प्राप्त करने पर वापस किया जा सकता है।

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

Answer 2

इसका प्रोटोकॉल स्टेटलेसनेस से कोई लेना देना नहीं है। स्टेटलेसनेस केवल इतना कहता है कि सर्वर एक बचत सत्र से संबंधित राज्य नहीं होना चाहिए (http://en.wikipedia.org/wiki/Stateless_protocol)।

आपके मामले में, उपयोगकर्ता संसाधनों सत्र स्थिति नहीं हैं - वे लगातार संसाधनों पर संग्रहीत और सर्वर द्वारा उजागर कर रहे हैं। ग्राहक को इस चेक को करने के लिए मजबूर करने के लिए wrt statelessness का कोई कारण नहीं है (इसे सभी उपयोगकर्ता संसाधनों को लाने और जांचने के द्वारा), और यह सर्वर को ऐसा करने के लिए और अधिक समझ में आता है। चाहे यह नया सर्वर संसाधन पोस्ट करने के एक हिस्से के रूप में सर्वर द्वारा किया गया हो, या कोई अलग संसाधन मौजूद है जो इस चेक को सक्षम करता है - यह अनिवार्य रूप से कोई फर्क नहीं पड़ता क्योंकि सर्वर इस चेक को किसी भी तरह से कर रहा है। यदि आप पहले से जांचने के लिए एक अलग संसाधन का उपयोग करते हैं कि क्या कोई नया उपयोगकर्ता पोस्ट करना ठीक है, और फिर वास्तव में पोस्ट करने के लिए एक नया अनुरोध करें - तो डुप्लिकेट ई-मेल पते की संभावना है। ऐसे मामलों में, अपेक्षित व्यवहार यह है कि सर्वर क्लाइंट को सूचित करता है कि POST अनुरोध विफल रहा है (उचित HTTP प्रतिक्रिया कोड का उपयोग करके, जैसा कि पहले अनुरोध के लिए होगा जिसके द्वारा क्लाइंट ने चेक किया है कि ई-मेल ठीक है)।

संक्षेप में: सर्वर "जाँच" होता है, और ग्राहक, जिसमें सर्वर को सूचित करता है यह है कि जांच में विफल स्थितियों को संभालने के लिए सक्षम होना चाहिए।