पुस्तक "एपीआई का सतत विकास। बदलते तकनीकी परिदृश्य में सही निर्णय

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

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

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

अंश। एपीआई सिस्टम

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

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

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

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

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

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

हम अधिक से अधिक संगठनों को ऐसा करते हुए देखते हैं। लेकिन इसमें सबसे महत्वपूर्ण बात यह समझना और सुनिश्चित करना है कि डिजाइनरों के लिए मैनुअल लगातार अपडेट किए जाते हैं: नए तरीकों का मूल्यांकन और अनुमोदन किया जाता है, पुराने तरीके प्रचलन से बाहर आते हैं, और इन परिवर्तनों के पीछे मुख्य प्रेरक शक्ति संगठन में एपीआई तरीकों का लगातार विकसित होना है।

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

पुरातत्व एपीआई

हालाँकि अब हम बड़ी संख्या में ऐसे संगठन देखते हैं जो केवल एपीआई के साथ कार्यक्रम बनाना शुरू कर रहे हैं, यह याद रखना महत्वपूर्ण है कि किसी भी संगठन में जो सूचना प्रौद्योगिकी का उपयोग करते हैं, लगभग निश्चित रूप से कुछ एपीआई हैं जिनका उपयोग लंबे समय से किया जा रहा है।

परिभाषा के आधार पर, एपीआई एक ऐसा इंटरफ़ेस है जो दो सॉफ्टवेयर घटकों को बातचीत करने की अनुमति देता है। यदि आप नेटवर्क एपीआई की आधुनिक समझ की परिभाषा को कम करते हैं, तो यह कोई भी इंटरफ़ेस है जो दो सॉफ्टवेयर घटकों को नेटवर्क के माध्यम से बातचीत करने की अनुमति देता है।

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

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

PROTO एपीआई

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

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

बड़े पैमाने पर एपीआई प्रबंधन

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

• केंद्रीकृत एकीकरण ने हमें अतीत के विशिष्ट उद्यम आईटी वास्तुकला को लाया है। मुख्य रूप से ड्राइविंग बल कार्यों के निष्पादन का मानकीकरण था ताकि उन्हें बेहतर और न्यूनतम लागत प्रदान की जा सके। एकीकरण का एक उच्च स्तर वास्तव में अनुकूलन को सरल करता है, लेकिन एक ही समय में परिवर्तन करने और अंतिम प्रणाली को विकसित करने की क्षमता को प्रभावित करता है।
• विकेंद्रीकरण इसके विपरीत है। इसका सबसे सुलभ और बड़े पैमाने पर उदाहरण इंटरनेट है। यहां मुख्य ड्राइविंग बल कार्यों तक पहुंच का मानकीकरण है ताकि आप उन्हें कई अलग-अलग तरीकों से प्रदान कर सकें जो लगातार विकसित हो रहे हैं। उसी समय, फ़ंक्शन उपलब्ध रहते हैं, क्योंकि एक्सेस फ़ंक्शंस की बातचीत पर सामान्य समझौतों पर आधारित होती है। विकेंद्रीकरण का मुख्य लक्ष्य सुसंगतता ( http://bit.ly/2FpcUpf ) को कमजोर करना है, अर्थात, अन्य भागों को बदलने की आवश्यकता के बिना समग्र प्रणाली के व्यक्तिगत भागों में परिवर्तन को सुविधाजनक बनाना।

निर्णय और निष्पादन

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

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

प्लेटफ़ॉर्म सिद्धांत

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

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

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

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

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

आप इस टेम्पलेट को एपीआई सिस्टम और अनुप्रयोगों के लिए एपीआई प्लेटफॉर्म बनाने के विचार दोनों पर लागू कर सकते हैं।

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

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

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

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

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

सिद्धांत, प्रोटोकॉल और टेम्पलेट

पिछले भाग से मुख्य निष्कर्ष: मंच को कुछ करने के लिए एक विशिष्ट तरीके की आवश्यकता नहीं होनी चाहिए (प्रश्न का उत्तर "कैसे?") या एक विशिष्ट स्थान (प्रश्न का उत्तर "कहां?")। वास्तुकला के निरंतर विकास के लिए एक अच्छा मंच बनाया गया है, अर्थात, मंच की वास्तुकला (और न केवल उत्पाद की वास्तुकला) लगातार विकसित हो रही है, और सभी को एक ही बार में विकसित नहीं किया जाता है, ताकि यह अपने अस्तित्व के सभी समय अपरिवर्तित रहे।

संपर्क वास्तुकला विकास

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

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

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

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

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

• सिद्धांत मौलिक अवधारणाएं हैं जो मंच की बहुत नींव पर निर्मित होती हैं। इंटरनेट के मामले में, इन सिद्धांतों में से एक यह है कि संसाधनों को एक समान संसाधन पहचानकर्ता (यूआरआई) द्वारा मान्यता प्राप्त है, और फिर यूआरआई-पहचान प्रोटोकॉल इन संसाधनों के साथ बातचीत करने की अनुमति देता है। इस प्रकार, यद्यपि हम (कम से कम सिद्धांत में) HTTP के बिना इंटरनेट पर जा सकते हैं (और इस अर्थ में हम पहले से ही आगे बढ़ रहे हैं क्योंकि हर जगह प्रोटोकॉल HTTPS में बदल रहे हैं), यह कल्पना करना मुश्किल है कि संसाधनों के बिना इंटरनेट पर जाना संभव है। सिद्धांत एपीआई की शैलियों में परिलक्षित होते हैं, क्योंकि शैलियों विभिन्न मौलिक अवधारणाओं पर आधारित हैं।
• , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
• — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .

, . , , . , -, .

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

API . , , , , , . API — , , .

API

API . , , . , «» API, , API, .

API .

• API (, / ) . , API RPC — , API REST .
• API . , API HTTP HTTP.
• API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
• API , API ( «» . 188). : API , API, .

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

सबसे आम एपीआई प्रणाली प्रबंधन पैटर्न में से एक छड़ी के बजाय एक छड़ी के साथ भाषा के पुन: उपयोग को बढ़ावा देना है।

• , , , , . , .
• , , . , . , , .

. , , , .

« » - - , . XML/JSON. XML-, API JSON ( , , , ).

API API

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

, , API API (, , API). API API. API ( — «» « API» ), API . , .

• , 10 .
• , status, .
• प्रत्येक सेवा से स्थिति की जानकारी एकत्र करें और इसे / संग्रह / कल्पना / प्रक्रिया करें।

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

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

«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .

एपीआई डिजाइन एलिमेंट बनने वाली विधि के साथ समस्या का समाधान बड़े एपीआई सिस्टम के प्रबंधन को आसान बनाता है क्योंकि कुछ डिजाइन तत्वों को एपीआई के बीच दोहराया जाता है और स्वचालन के लिए इस्तेमाल किया जा सकता है।

प्रणाली की समझ

API , — , . . . — , .

, : , API, API. , , , , , , , API API, API API. API , , .

. , API, , , . , -, .

API API, , , , -. , : , API , , , , .

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

लेखकों के बारे में

— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.

, API . IETF W3C. , , EMC, Siemens CA Technologies.

. API UX , API .

, , , , - . API API , , , API .

»
»
»

25% — API

e-mail .