200 के लिए बाकी जुनून

मैं बहुत पहले से यह लेख लिखना चाहता था। मैं सोचता रहा कि कौन सा पक्ष अधिक सही ढंग से प्रवेश कर सकता है। लेकिन, हाल ही में, हाल ही में, ऐसा ही एक लेख हैबे पर दिखाई दिया, जिसके कारण एक गिलास में तूफान आया। जिस बात ने मुझे सबसे ज्यादा हैरान किया, वह यह था कि लेख को minuses में संचालित किया जाने लगा, हालांकि इसने कुछ घोषित भी नहीं किया, बल्कि REST में वेब सर्वर प्रतिक्रिया कोड का उपयोग करने पर सवाल उठाया। बहस गरम हो गई। और एपोथोसिस यह था कि लेख मसौदा में गया था ... टिप्पणियों, राय, आदि के किलोबाइट। बस गायब हो गया। कई लोग कर्मो के शिकार बन गए, विचार करें, कुछ नहीं के लिए :)

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

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

HTTP

पहली बात यह है कि परतों को बहुत स्पष्ट रूप से अलग करना है। परिवहन परत http है। खैर, वास्तव में बाकी। यह सब कुछ स्वीकार करने और इसमें "अपने आप" एक मौलिक रूप से महत्वपूर्ण बात है। पहले http की ही बात करते हैं।

मैंने "ट्रांसपोर्ट लेयर" शब्द का इस्तेमाल किया। और मैंने आरक्षण नहीं किया। बात यह है कि http स्वयं ही क्लाइंट और सर्वर के अनुरोधों को tcp / ip की परवाह किए बिना क्लाइंट और सामग्री तक पहुँचाने के कार्यों को कार्यान्वित करता है। हां, यह tcp / ip पर आधारित है। और ऐसा लगता है, इसे अपने परिवहन के रूप में माना जाना आवश्यक है। लेकिन नहीं। और यहाँ क्यों है - सॉकेट कनेक्शन प्रत्यक्ष नहीं हैं, अर्थात्। यह क्लाइंट-सर्वर कनेक्शन नहीं है। HTTP अनुरोध और http प्रतिक्रिया दोनों एक टन सेवाओं के माध्यम से लंबा रास्ता तय कर सकते हैं। वे इसके विपरीत एकत्र या विघटित हो सकते हैं। कैश किया जा सकता है, संशोधित किया जा सकता है।

यानी http अनुरोध और http प्रतिक्रिया दोनों का अपना मार्ग है। और यह न तो अंतिम छोर पर निर्भर है, न ही अंतिम मोर्चे पर। मैं आपसे इस पर विशेष ध्यान देने के लिए कहता हूं।

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

और यहां यह समझना महत्वपूर्ण है - हमें प्रतिक्रिया कोड की आवश्यकता क्यों है? बात यह है कि ऊपर वर्णित पूरा मॉडल उनके आधार पर निर्णय लेता है। यानी ये कोड हैं जो आपको http रूटिंग के दौरान बुनियादी ढाँचे और परिवहन निर्णय लेने की अनुमति देते हैं।

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

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

500 के मामले में, आंकड़े हमारी सहायता के लिए आते हैं। नोड का स्थानीय वेब-सर्वर बड़ी संख्या में 500 उत्तरों के साथ नोड को अनुपलब्ध स्थिति में अनुवाद कर सकता है। इस मामले में, इस नोड से संपर्क करने वाले बैलेंसर को 503 प्रतिक्रिया मिलेगी और इसे स्पर्श नहीं करेगा। परिणाम समान है, लेकिन अब, यह समाधान सार्थक है और "झूठी" प्रतिक्रियाओं को समाप्त करता है।

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

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

बाकी

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

क्या आपने कभी सोचा है कि REST के लिए एक अलग परिवहन का आविष्कार क्यों नहीं किया गया? उदाहरण के लिए, वेबसोकेट के लिए यह है। हां, यह http से भी शुरू होता है, लेकिन फिर, कनेक्शन स्थापित होने के बाद, यह आम तौर पर एक अलग गीत है। रेस्ट के लिए ही क्यों नहीं?

उत्तर सरल है - क्यों? एक सुंदर, तैयार, सत्यापित प्रोटोकॉल है - http। यह अच्छी तरह से तराजू। आपको जटिल, अत्यधिक सुलभ सेवाओं को लागू करने की अनुमति देता है जो एक भारी भार का सामना कर सकते हैं। जरूरत है कि कुछ वैचारिक नियमों को पेश किया जाए ताकि डेवलपर्स एक दूसरे को समझ सकें।

यहाँ से एक सरल, स्पष्ट निष्कर्ष का अनुसरण किया जाता है - http में निहित सब कुछ REST में निहित है। ये अविभाज्य संस्थाएं हैं। कोई अलग REST हैडर नहीं है, एक संकेत भी नहीं है कि REST REST है। किसी भी REST सर्वर के लिए, अनुरोध बिल्कुल किसी अन्य के समान है। यानी REST केवल वह चीज है जो हमारे मन में है।

REST http प्रतिक्रिया कोड

आइए इस बारे में बात करें कि आपके सर्वर को REST अनुरोध का क्या जवाब देना चाहिए? व्यक्तिगत रूप से, यह मुझे लगता है कि उपरोक्त सभी से, उत्तर पहले से ही स्पष्ट है, क्योंकि REST किसी अन्य अनुरोध से अलग नहीं है, यह बिल्कुल समान नियमों के अधीन होना चाहिए। प्रतिक्रिया कोड REST का एक अभिन्न अंग है और प्रतिक्रिया के सार के लिए प्रासंगिक होना चाहिए। यानी यदि ऑब्जेक्ट अनुरोध द्वारा नहीं मिला, तो यह 404 है, अगर ग्राहक ने गलत अनुरोध 400, आदि किया है। लेकिन, ज्यादातर, बहस वहाँ खत्म नहीं होती है। इसलिए, मैं जारी रखूंगा।

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

लेकिन सबसे अधिक संभावना है ... वह सही नहीं है। और गलतियाँ होती हैं। और ऐसा होता है कि वे हमारे नियंत्रण से परे परिस्थितियों के कारण होते हैं। और यहाँ एक विशिष्ट समाधान अपनी स्वयं की त्रुटि कोडिंग प्रणाली बनाना है। क्या यह बुरा है? हाँ, यह बुरा है। यह सुपर खराब है। आइए जानें इसका कारण।

और इसलिए, कोड 200 को एकमात्र सही के रूप में लेते हुए, हम सिस्टम की संपूर्ण परत (महत्वपूर्ण परत) को विकसित करने की जिम्मेदारी लेते हैं - त्रुटि से निपटने। यानी इस परत को विकसित करने के लिए कई लोगों के श्रम को स्क्रैप करने के लिए भेजा जाता है। और उसके "साइकिल" का निर्माण शुरू होता है। लेकिन यह मेगा-बिल्डिंग असफलता के लिए बर्बाद है।

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

आइए सवाल पर वापस जाएं - यह सही क्यों है? क्योंकि:

1. कोड 500 एक बुनियादी ढांचा टोकन है, जिसके आधार पर समस्या उत्पन्न होने वाले नोड को निष्क्रिय किया जा सकता है;
2. 5xx कोड वे हैं जिनकी निगरानी की जा रही है और यदि ऐसा कोई कोड आता है, तो कोई भी मॉनिटरिंग सिस्टम आपको तुरंत इसकी सूचना देगा। और समय में सहायता सेवा समस्या के समाधान से जुड़ने में सक्षम होगी;
3. आप अतिरिक्त कोड नहीं लिखते हैं। इस पर कीमती समय बर्बाद मत करो। वास्तुकला को जटिल मत करो। आप के लिए असामान्य समस्याओं से नहीं निपटते हैं - आप आवेदन कोड लिखते हैं। वे आपसे क्या चाहते हैं। वे किसके लिए भुगतान कर रहे हैं?
4. एक निशान जो गलती से गिर जाता है 500 इसे पार करने के आपके प्रयासों की तुलना में बहुत अधिक उपयोगी होगा।
5. यदि REST अनुरोध 500 कोड लौटाता है, तो प्रतिक्रिया को संसाधित करने के समय पहले से ही सामने वाले को पता चल जाएगा कि इसे क्या संसाधित करना है। इसके अलावा, मामले का सार किसी भी तरह से नहीं बदलेगा, आपको 200 और 500 दोनों में से कुछ भी समझदार नहीं मिला है। लेकिन 500 से आपको एक लाभ प्राप्त हुआ है - यह अहसास कि यह एक अज्ञात त्रुटि है।
6. कोड 500 एक गारंटी के साथ आएगा। चाहे आपने अपना कोड कितना भी बुरा या अच्छा क्यों न लिखा हो। यह आपका फुलक्रम है।

अलग-अलग, मैं कोड 200 के पूरे "बॉडी" में एक कील ठोक दूंगा:

7. यहां तक ​​कि अगर आप अपने अनुरोधों के अलावा 200 से सर्वर से अन्य प्रतिक्रिया कोड से बचने की बहुत कोशिश करते हैं, तो आप ऐसा नहीं कर सकते। कोई भी मध्यस्थ सर्वर किसी भी कोड के साथ आपके अनुरोध का जवाब दे सकता है। और आप इस तरह के जवाब को सही ढंग से प्रोसेस करें।

कुल मिलाकर, तार्किक स्तर पर, कोड 200 के लिए संघर्ष व्यर्थ है।

अब बुनियादी ढांचे के स्तर पर वापस आते हैं। बहुत बार मैं राय सुनता हूं - 5xx कोड एक आवेदन स्तर नहीं है, इसे समर्थन नहीं दिया जा सकता है। अहम, ठीक है ... बयान में ही विरोधाभास है। आप दे सकते हैं। लेकिन यह कोड एक एप्लिकेशन स्तर नहीं है। यह अधिक सच है। इसे समझने के लिए, मैं इस मामले पर विचार करने का प्रस्ताव करता हूं:

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

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

कहां और किस कोड का इस्तेमाल करना है

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

स्वीकृत मानक हैं। वे आसानी से मिल सकते हैं और, फिर से, मैं स्पष्ट प्रमाण नहीं दूंगा। लेकिन, मैं आपको अविश्वास दे दूंगा - developer.mozilla.org/en/docs/Web/HTTP/Status
वह क्यों? बात यह है कि "कोड को समझने" के कार्यान्वयन और संदर्भ के आधार पर कोड हैंडलर अलग-अलग व्यवहार कर सकते हैं। उदाहरण के लिए, ब्राउज़रों के पास प्रतिक्रिया कोड के आधार पर एक कैशिंग रणनीति है। और कुछ सेवाओं के अपने स्वयं के, कस्टम कोड हैं। उदाहरण के लिए, CloudFlare।

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

बुराई की जड़ें

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

बुराई की जड़, यह मुझे लगता है, इस तथ्य में निहित है कि कोड 500 पहली चीज है जो एक वेब डेवलपर अपने पेशेवर कैरियर में सामना करता है। इसे बचपन की चोट कहा जा सकता है। और कोड 200 पाने के लिए पहले उबले हुए उनके सभी प्रयास समाप्त हो गए।

वैसे, किसी कारण से, एक ही चरण में, एक मजबूत राय विकसित होती है कि कोड 200 के साथ केवल एक शरीर के साथ जवाब दिया जा सकता है। बेशक, यह ऐसा नहीं है, और कोई भी जवाब किसी भी कोड के साथ "आ सकता है"। कोड एक कोड है। शरीर ही शरीर है।

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

पुनश्च: उल्लिखित लेख के लेखक ने इसे ड्राफ्ट - habr.com/en/post/440382 से पुनर्स्थापित किया, ताकि आप खुद को इसके साथ भी परिचित कर सकें।

PPS: मैंने REST में प्रासंगिक प्रतिक्रिया कोड का उपयोग करने की आवश्यकता के सभी पहलुओं को बताने की कोशिश की। मैं टिप्पणियों का जवाब नहीं दूंगा, कृपया मुझे सही ढंग से समझें। मैं उन्हें बहुत ध्यान से पढ़ूंगा, लेकिन मुझे जोड़ने के लिए कुछ भी नहीं है। लेख पढ़ने के लिए पर्याप्त धैर्य रखने के लिए बहुत बहुत धन्यवाद!