🧑🏿‍🤝‍🧑🏾 🧚🏼 👰🏻 अच्छा क्लाइंट सर्वर आर्किटेक्चर 🧑🏼‍🤝‍🧑🏻 😰 😚

मैं तुरंत एक आरक्षण करूँगा जो कि मैं एक मोबाइल डेवलपर हूं, और यह लेख मुख्य रूप से क्लाउड के दूसरी तरफ डेवलपर्स के लिए है - मोबाइल फोन ताकि वे इसके बारे में सब जानते हों। मैंने कई साल पहले आखिरी वेब एप्लिकेशन लिखा था और वेब शब्दावली में गलत हो सकता है। कुछ नवीनतम रुझानों के बारे में पता नहीं है। .NET, PHP, या जावा वेब सेवाओं में, इसलिए कड़ाई से न्याय न करें।

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

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

हैंडलिंग में त्रुटि

सबसे अधिक बार मैं कुछ इस तरह से आया:

HTTP code 200 (OK) <?xml version="1.0" encoding="utf-8"?><Body> <Result> <Success>false</Success> <Error>The username or password is incorrect. Please try again.</Error> </Result> <Response> </Response> </Body>

यानी अनुरोध को संसाधित करने का परिणाम सबसे दिए गए XML में निहित है, HTTP रिटर्न कोड 200 है, अर्थात सामान्य, डेटा को सामान्य RPC के रूप में प्रस्तुत किया जाता है। उदाहरण के लिए, एक समान तरीके से, SOAP प्रोटोकॉल में त्रुटि हैंडलिंग 90% मामलों में लागू की जाती है।

विशेष रूप से उन्नत मामलों में, जो विशेष रूप से हिंदू कोड की विशेषता है, एक्सएमएल के विभिन्न स्थानों में गलत हो सकता है, जो कि पार्सिंग को काफी जटिल करता है, अति व्यस्तता की ओर जाता है और एक ऊब प्रोग्रामर को प्रसन्न करता है।

लेकिन आइए सिद्धांत रूप में इस दृष्टिकोण के नुकसान को देखें।

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

लेकिन संदेश के पाठ का आविष्कार करने के लिए वेब प्रोग्रामर के समय को बर्बाद कर दिया गया, और चैनल अनावश्यक जानकारी से भरा हुआ था।

समस्या को कैसे हल करें?

HTTP प्रोटोकॉल कई वर्षों से अपने स्वयं के त्रुटि कोड जोड़ने में सक्षम है, इसके लिए उन्हें केवल 512 से 597 तक की सीमा का होना चाहिए। यह संख्या, मुझे यकीन है, मध्यम आकार के अनुप्रयोग में सभी संभावित त्रुटियों को कवर करने के लिए पर्याप्त है। जाहिर है, इससे क्या लाभ मिलता है, लेकिन फिर भी संक्षेप में:

अतिरेक नहीं। हेडर में केवल HTTP कोड प्रसारित होता है, अनुरोध बॉडी बस नहीं है।
क्लाइंट की ओर, अनुरोध प्रसंस्करण कोड की केवल दो शाखाएँ हैं - सफल निष्पादन, या निष्पादन के दौरान एक त्रुटि (दोनों कॉलबैक पहले से ही किसी भी अनुरोध पुस्तकालय में बॉक्स से बाहर लागू होते हैं)। कोई शाखा नहीं है "अनुरोध सफल था, लेकिन प्रतिक्रिया निकाय में एक तार्किक त्रुटि हो सकती है"।

यह देखना भी दिलचस्प होगा कि HTTP मानक और अंग्रेजी भाषा विकिपीडिया इस स्थिति को कैसे देखते हैं:

5xx सर्वर त्रुटि

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

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

हालांकि हम सामान्यीकरण नहीं करेंगे - HTTP कोड का उपयोग करने का विचार मुझे कई साल पहले उसी अमेरिकी के लिए प्रेरित करता था।

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

सत्र या कुकी बाँधना।

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

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

मान लीजिए कि आपका मोबाइल एप्लिकेशन किसी वेबसाइट की कार्यक्षमता का केवल 70% लागू करता है। शेष 30% कार्यक्षमता केवल वेब पर उपलब्ध है, और आपके एप्लिकेशन में केवल प्रासंगिक वेब पृष्ठों के लिंक हैं।

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

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

HTML वापसी

यह पहले से ही खुद को वेब सर्वर के डिजाइन की ओर ले जाता है, जो मूल रूप से केवल ब्राउज़र के लिए तेज किया गया था। त्रुटियां 403, 404, और कभी-कभी और भी अधिक जटिल, अक्सर HTML पृष्ठ के रूप में दी जाती हैं, जिसमें अक्सर मोबाइल एप्लिकेशन में प्रदर्शित करने के साधन नहीं होते हैं। अधिक सटीक रूप से, धन होते हैं, लेकिन जब वह एक वेब दृश्य के अंदर एक सफेद पृष्ठभूमि पर भारी काले एरियल ब्लैक द्वारा "404 पृष्ठ नहीं मिला" देखता है, तो मोबाइल उपयोगकर्ता डर जाएगा और एप्लिकेशन को बंद कर देगा।

याद रखें, सर्वर को वेब सेवाओं के लिए किसी भी कॉल के लिए XML (या JSON) प्रदान करना चाहिए, और केवल उस प्रारूप में जो मूल रूप से सहमत था। एक मोबाइल डेवलपर सर्वर से आने वाले HTML के साथ कुछ भी अच्छा नहीं कर सकता है।

WSDL का उपयोग करें

Microsoft प्रौद्योगिकियों पर, स्थिति अभी भी कुछ भी नहीं है - उनकी अधिकांश आधुनिक प्रौद्योगिकियां WSDL को बॉक्स से बाहर का समर्थन करती हैं। आप PHP और जावा के बारे में नहीं कह सकते हैं - विशेष रूप से PHP डेवलपर्स मैन्युअल रूप से नियमित पेज बनाने के बहुत शौकीन हैं, जो अनिवार्य रूप से वेब सेवाएं हैं। लेकिन एक WSDL- संगत वेब सेवा के साथ एकीकृत करने के लिए, एक मोबाइल डेवलपर को कोड उत्पन्न करने के लिए उपकरण का उपयोग करने की आवश्यकता होती है, जबकि मैन्युअल रूप से संकलित वेब सेवाओं की प्रतिक्रियाओं को भी पार्स करने की आवश्यकता होती है।

सच है, यहां सूक्ष्मताएं हैं - एमएस और सन (ओरेकल) से मानक डब्ल्यूएसडीएल कार्यान्वयन अभी भी असंगतताएं हैं, लेकिन फिर भी एक फाइल के साथ इन असंगतताओं को ठीक करने के लिए तेजी से सब कुछ लिखना है।

निष्कर्ष

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