👊🏿 🅰️ 💣 डब्ल्यूजी कॉन्ट्रैक्ट एपीआई: सेवाओं का चिड़ियाघर 🔰 🏠 🌍

एक सॉफ्टवेयर सिस्टम में घटकों की संख्या में वृद्धि के साथ, आमतौर पर इसके विकास में भाग लेने वाले लोगों की संख्या भी बढ़ती है। नतीजतन, विकास की गति बनाए रखने और रखरखाव में आसानी के लिए, एपीआई के संगठन के दृष्टिकोण को विशेष ध्यान देने का विषय होना चाहिए।

यदि आप यह देखना चाहते हैं कि वॉरगामिंग प्लेटफ़ॉर्म टीम सौ से अधिक वेब सेवाओं की एक-दूसरे के साथ बातचीत करने की प्रणाली की जटिलता से कैसे निपटती है, तो बिल्ली का स्वागत है।

सभी को नमस्कार! मेरा नाम वेलेंटाइन है और मैं Wargaming पर प्लेटफार्म पर एक इंजीनियर हूं। उन लोगों के लिए जिन्हें यह पता नहीं है कि प्लेटफ़ॉर्म क्या है और यह क्या करता है, मैं अपने सहयोगियों में से एक के हालिया प्रकाशन का लिंक यहां छोड़ दूंगा - max_posedon

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

थोड़ा सा इतिहास

"टैंक" की बढ़ती लोकप्रियता हिमस्खलन जैसी हो गई, और जैसा कि आमतौर पर ऐसे मामलों में होता है, खेल के चारों ओर बुनियादी ढाँचा तेजी से विकसित होने लगा। नतीजतन, खेल जल्दी से विभिन्न वेब सेवाओं के साथ आगे निकल गया, और मेरे टीम में शामिल होने के समय, उनका स्कोर पहले से ही दसियों में जा रहा था (अब, 100 से अधिक मंच घटक काम करते हैं और कंपनी को लाभ पहुंचाते हैं)।

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

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

इसके साथ मैं ऐतिहासिक भ्रमण समाप्त करना चाहता हूं और आखिरकार, हमारे एक तकनीकी समाधान के बारे में बात करता हूं, जो सेवाओं की बढ़ती संख्या के कारण होने वाली जटिलता पर नियंत्रण रखने में मदद करता है। इसके अलावा, यह नई कार्यक्षमता विकसित करने की लागत को कम करता है और मंच के साथ एकीकरण को बहुत सरल करता है।

कॉन्ट्रैक्ट एपीआई से मिलें

प्लेटफॉर्म के अंदर, हम इसे कॉन्ट्रैक्ट एपीआई कहते हैं। इसके मूल में, यह हमारे स्टैक (Erlang / Elixir, Java / Scala, Python) से प्रत्येक तकनीक के लिए प्रलेखन और ग्राहक पुस्तकालयों के एक समूह द्वारा प्रस्तुत एकीकरण ढांचा है। इसे विकसित किया जा रहा है, सबसे पहले, एक दूसरे के साथ मंच के घटकों के एकीकरण को सरल बनाने के लिए। दूसरा, हमें निम्नलिखित समस्याओं का समाधान करने में मदद करने के लिए:

कार्यक्रम इंटरफेस की शैलीगत अंतर
प्रत्यक्ष अंतर-घटक निर्भरता की उपस्थिति
आज तक दस्तावेज रखना
आत्मनिरीक्षण और डिबगिंग एंड-टू-एंड कार्यक्षमता

तो, पहले चीजें पहले।

सॉफ्टवेयर इंटरफेस में स्टाइलिस्टिक अंतर

मेरी राय में, कई कारकों के संयोजन के परिणामस्वरूप यह समस्या उत्पन्न हुई:

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

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

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

इसलिए हमें एक वैचारिक रूप से एकीकृत प्लेटफ़ॉर्म एपीआई मिला जो एक एकल उत्पाद की तरह दिखता था, इस तथ्य के बावजूद कि यह वास्तव में कई तकनीकी घटकों का उपयोग करके कई मंच घटकों पर लागू किया गया था।

प्रत्यक्ष अंतर-घटक निर्भरता की उपस्थिति

हमारी यह समस्या इस तथ्य में स्वयं प्रकट हुई कि प्रत्येक मंच घटक को यह जानना आवश्यक था कि विशेष रूप से उस कार्यक्षमता की कौन सेवा करता है, जिसकी उसे आवश्यकता है।

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

हमने कई विकल्पों का चयन किया। इनमें से, हमने विशेष रूप से ध्यान से विचार किया:

प्रत्येक घटक पर सेवा खोज प्रोटोकॉल का कार्यान्वयन।
सही मंच घटक के लिए क्लाइंट अनुरोधों को पुनर्निर्देशित करने के लिए एक मध्यस्थ का उपयोग करना।
मैसेजिंग ब्रोकर के रूप में मैसेजिंग ब्रोकर का उपयोग करना।

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

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

आज तक दस्तावेज रखे

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

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

आत्मनिरीक्षण और डिबगिंग एंड-टू-एंड कार्यक्षमता

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

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

कॉन्ट्रैक्ट एपीआई के शीर्ष पर हमने और क्या विकसित किया

इसके मुख्य उद्देश्य और उपरोक्त समस्याओं को हल करने के अलावा, अनुबंध एपीआई ने हमें कई उपयोगी सेवाओं को लागू करने की अनुमति दी।

प्लेटफ़ॉर्म कार्यक्षमता तक पहुंचने के लिए प्रवेश द्वार

अनुबंध के रूप में एपीआई के मानकीकरण ने हमें HTTP के माध्यम से प्लेटफ़ॉर्म कार्यक्षमता के लिए एकल पहुंच बिंदु विकसित करने की अनुमति दी। इसके अलावा, नई कार्यक्षमता (अनुबंध) के आगमन के साथ, हमें किसी भी तरह से इस एक्सेस प्वाइंट को संशोधित करने की आवश्यकता नहीं है। यह भविष्य के सभी अनुबंधों के साथ संगत है। यह आपको सामान्य HTTP इंटरफ़ेस का उपयोग करके एक एकल उत्पाद के रूप में मंच के साथ काम करने की अनुमति देता है।

मास संचालन सेवा

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

एकीकृत मंच त्रुटि हैंडलिंग

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

ऑटो जनरेट यूजर इंटरफेस

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

प्लेटफ़ॉर्म लॉगिंग

यह घटक अभी तक लागू नहीं हुआ है और विकास के अधीन है। लेकिन भविष्य में, यह मंच पर किसी भी व्यावसायिक कार्य के लॉगिंग को चालू और बंद करने की अनुमति देगा, इस जानकारी को सीधे संदेश ब्रोकर से हटाता है, बिना किसी दुष्प्रभाव के जो अंतःक्रियात्मक घटकों को प्रतिकूल रूप से प्रभावित करता है।

कॉन्ट्रैक्ट एपीआई का मुख्य उद्देश्य

लेकिन फिर भी, अनुबंध एपीआई का मुख्य उद्देश्य प्लेटफॉर्म घटकों को एकीकृत करने की लागत को कम करना है।

डेवलपर्स को पुस्तकालयों द्वारा परिवहन स्तर से अलग किया जाता है जिसे हमने अपनी प्रत्येक प्रौद्योगिकी स्टैक के लिए विकसित किया था। यह हमें पैंतरेबाज़ी के लिए कुछ जगह देता है अगर हमें संदेश दलाल को बदलना है या यहां तक कि पॉइंट-टू-पॉइंट इंटरैक्शन पर स्विच करना है। लाइब्रेरी का बाहरी इंटरफ़ेस अपरिवर्तित रहेगा।

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

अजगर अनुबंध कॉल उदाहरण

from platform_client import Client client = Client(contracts_path=CONTRACTS_PATH, url=AMQP_URL, app_id='client') client.call("ban-management.create-ban.v1", { "wgid": 1234567890, "reason": "Fraudulent activity", "title": "ru.wot", "component": "game", "bantype": "access_denied", "author_id": "v_nikonovich", "expires_at": "2038-01-19 03:14:07Z" }) { u'ban_id': 31415926, u'wgid': 1234567890, u'title': u'ru.wot', u'component': u'game', u'reason': u'Fraudulent activity', u'bantype': u'access_denied', u'status': u"active", u'started_at': u"2019-02-15T15:15:15Z", u'expires_at': u"2038-01-19 03:14:07Z" }

एक ही अनुबंध कॉल, लेकिन अमृत का उपयोग करना

 :platform_client.call("ban-management.create-ban.v1", %{ "wgid" => 1234567890, "reason" => "Fraudulent activity", "title" => "ru.wot", "component" => "game", "bantype" => "access_denied", "author_id" => "v_nikonovich", "expires_at" => "2038-01-19 03:14:07Z" }) {:ok, %{ "ban_id" => 31415926, "wgid" => 1234567890, "title" => "ru.wot", "conponent" => "game", "reason" => "Fraudulent activity", "bantype" => "access_denied", "status" => "active", "started_at" => "2019-02-15T15:15:15Z", "expires_at" => "2038-01-19 03:14:07Z" }}

अनुबंध के स्थान पर "प्रतिबंध- management.create-ban.v1" कोई अन्य प्लेटफ़ॉर्म कार्यक्षमता हो सकती है, उदाहरण के लिए: "खाता-प्रबंधन.rename-account.v1" या "सूचना-Center.create-sms-notification.v1"। और यह सब प्लेटफॉर्म के साथ एकीकरण के इस एकल बिंदु के माध्यम से उपलब्ध होगा।

यदि आप सर्वर डेवलपर के दृष्टिकोण से अनुबंध एपीआई प्रदर्शित नहीं करते हैं तो अवलोकन अधूरा होगा। ऐसी स्थिति पर विचार करें जिसमें एक डेवलपर को एक ही प्रतिबंध-प्रबंधन के लिए हैंडलर लागू करने की आवश्यकता है।

 from platform_server import BlockingServer, handler class CustomServer(BlockingServer): @handler('ban-management.create-ban.v1') def handle_create_ban(self, params, context): response = do_some_usefull_job(params) return response d = CustomServer(app_id="server", amqp_url=AMQP_URL, contracts_path=CONTRACTS_PATH) d.serve()

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

इस तथ्य के कारण कि हुड के तहत कॉन्ट्रैक्ट एपीआई को घटनाओं के आधार पर लागू किया जाता है, हमें अनुरोध / रिस्पांस स्क्रिप्ट के दायरे से परे जाने और व्यापक श्रेणी के इंटरैक्शन को लागू करने का अवसर मिलता है।

उदाहरण के लिए:

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

और यह उन परिदृश्यों की पूरी सूची नहीं है, जिन्हें इंटरैक्शन के इवेंट मॉडल के माध्यम से व्यक्त किया जा सकता है। यह उन लोगों की एक सूची है जो हम वर्तमान में उपयोग कर रहे हैं।

एक निष्कर्ष के बजाय

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

डब्ल्यूजी कॉन्ट्रैक्ट एपीआई: सेवाओं का चिड़ियाघर