एपीआई डेवलपमेंट की लाइफ़साइकल

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

हर संगठन का सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकल (एसडीएलसी) अलग होता है. अक्सर, एपीआई प्रॉक्सी डिप्लॉयमेंट को उन प्रोसेस के साथ सिंक और अलाइन करना ज़रूरी होता है जिनका इस्तेमाल आज आप अन्य ऐप्लिकेशन को डेवलप, टेस्ट, और डिप्लॉय करने के लिए करते हैं.

API Services, टूल और RESTful API उपलब्ध कराती है. इनकी मदद से, एपीआई प्रॉक्सी डिप्लॉयमेंट और मैनेजमेंट को अपने संगठन के एसडीएलसी में इंटिग्रेट किया जा सकता है. RESTful API का इस्तेमाल आम तौर पर स्क्रिप्ट या कोड लिखने के लिए किया जाता है. इससे एपीआई प्रॉक्सी को प्रोग्राम के हिसाब से डिप्लॉय किया जा सकता है. इसके अलावा, एपीआई प्रॉक्सी को एक एनवायरमेंट से दूसरे एनवायरमेंट में माइग्रेट किया जा सकता है. यह एक बड़ी ऑटोमेटेड प्रोसेस का हिस्सा होता है. इस प्रोसेस में, अन्य ऐप्लिकेशन को भी डिप्लॉय या माइग्रेट किया जाता है. API Services, आपके एसडीएलसी (या किसी और के एसडीएलसी) के बारे में कोई अनुमान नहीं लगाता. इसके बजाय, यह ऐसे छोटे-छोटे फ़ंक्शन दिखाता है जिन्हें आपकी डेवलपमेंट टीम, एपीआई डेवलपमेंट के लाइफ़साइकल को अपने-आप होने के लिए सेट करने और उसे ऑप्टिमाइज़ करने के लिए इस्तेमाल कर सकती है.

एपीआई सेवाओं के एपीआई के बारे में, एपीआई के रेफ़रंस में बताया गया है. एपीआई के बारे में जानकारी देने वाले रेफ़रंस पेज का इस्तेमाल शुरू करना लेख पढ़ें.

एनवायरमेंट

Apigee Edge पर मौजूद हर संगठन के पास, कम से कम दो डिप्लॉयमेंट एनवायरमेंट होते हैं. ये एपीआई प्रॉक्सी के लिए उपलब्ध होते हैं: 'test' और 'prod'. दोनों एनवायरमेंट के बीच का अंतर मनमाना होता है. हर एनवायरमेंट की पहचान, नेटवर्क पतों (यूआरएल) के अलग-अलग सेट से की जाती है. इसका लक्ष्य आपको ऐसा डोमेन उपलब्ध कराना है जिसमें एपीआई को बाहरी डेवलपर के लिए उपलब्ध कराने से पहले, एपीआई प्रॉक्सी बनाई और उनकी पुष्टि की जा सके.

इन एनवायरमेंट का इस्तेमाल करके, एपीआई प्रॉक्सी डेवलपमेंट को अपने एसडीएलसी के साथ सिंक किया जा सकता है. हर एनवायरमेंट को नेटवर्क पते से तय किया जाता है. इससे, उन एपीआई प्रॉक्सी के बीच ट्रैफ़िक को अलग-अलग किया जा सकता है जिन पर काम किया जा रहा है. साथ ही, उन एपीआई प्रॉक्सी के बीच भी ट्रैफ़िक को अलग-अलग किया जा सकता है जिन्हें रनटाइम के दौरान ऐप्लिकेशन ऐक्सेस कर रहे हैं. हर एनवायरमेंट के लिए उपलब्ध नेटवर्क पते, उस एनवायरमेंट में उपलब्ध VirtualHosts के सेट में तय किए जाते हैं.

इनबाउंड कनेक्शन के लिए, हर एनवायरमेंट में सर्वर टीएलएस/एसएसएल की सुविधा अपने-आप चालू हो जाती है. हर एनवायरमेंट में, दो VirtualHost पहले से तय किए गए हैं: default और secure. डिफ़ॉल्ट में एचटीटीपी पता तय किया जाता है, जबकि सुरक्षित में एचटीटीपी/एस पता तय किया जाता है. इसमें सर्वर-साइड टीएलएस/एसएसएल पहले से कॉन्फ़िगर होता है. एपीआई प्रॉक्सी कॉन्फ़िगरेशन में, यह बताया जाता है कि ProxyEndpoint को किन VirtualHosts पर सुनना चाहिए. प्रोडक्शन एनवायरमेंट में प्रमोट करते समय, आम तौर पर एचटीटीपी को बंद कर दिया जाता है. इसके लिए, एपीआई प्रॉक्सी कॉन्फ़िगरेशन से default VirtualHost को हटा दिया जाता है.

उदाहरण के लिए, यहां दिया गया ProxyEndpoint, एचटीटीपी और एचटीटीपीएस पर लिसन करता है.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

ProxyEndpoint कॉन्फ़िगरेशन से default VirtualHost को मिटाने पर, आपको एक ऐसी एपीआई प्रॉक्सी मिलती है जो सिर्फ़ एचटीटीपीएस पर काम करती है, एचटीटीपी पर नहीं.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के मुख्य मेन्यू में एनवायरमेंट को चुनकर, यह देखा जा सकता है कि किसी एनवायरमेंट में कौनसे VirtualHost उपलब्ध हैं.

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

एपीआई प्रॉक्सी को एनवायरमेंट में डिप्लॉय करना

एपीआई प्रॉक्सी बनाते समय, आपको यह तय करना होगा कि आपको किस एनवायरमेंट में काम करना है. प्रोडक्शन पर नई एपीआई प्रॉक्सी बनाई जा सकती है. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता, क्योंकि इससे एपीआई के तैयार होने से पहले ही डेवलपर को एपीआई उपलब्ध कराया जा सकता है. आम तौर पर, test में एपीआई प्रॉक्सी बनाकर शुरुआत करें. इसके बाद, टेस्टिंग के बाद उसे prod में प्रमोट करें.

ज़्यादा जानकारी के लिए, डिप्लॉयमेंट के बारे में जानकारी लेख पढ़ें.

टेस्ट में इटरेटिव डेवलपमेंट

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

प्रोडक्शन में प्रमोशन

जब किसी एपीआई प्रॉक्सी को पूरी तरह से लागू कर दिया जाता है और उसकी जांच कर ली जाती है, तब उसे 'prod' में प्रमोट किया जा सकता है. टेस्ट में मौजूद एपीआई प्रॉक्सी के वर्शन का इस्तेमाल, प्रोडक्शन एनवायरमेंट में डिप्लॉय किए गए एपीआई प्रॉक्सी के वर्शन को बदलने के लिए किया जाएगा.

एपीआई सेवाएं, एपीआई प्रॉक्सी को आसानी से डिप्लॉय करने की सुविधाएं देती हैं. इससे डिप्लॉयमेंट की प्रोसेस के दौरान, ऐप्लिकेशन और असली उपयोगकर्ताओं पर पड़ने वाले असर को कम किया जा सकता है.

स्क्रिप्टिंग डिप्लॉयमेंट

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

पर्यावरण से जुड़े संसाधन

प्रमोशन के दौरान ज़्यादा कंट्रोल पाने के लिए, हमारा सुझाव है कि आप सिर्फ़ टेस्ट में एपीआई प्रॉक्सी को दोहराएं. साथ ही, प्रोडक्शन में डिप्लॉय की गई एपीआई प्रॉक्सी में ज़रूरी बदलाव ही करें.

इसके लिए, आपको यह पक्का करना होगा कि हर एनवायरमेंट से जुड़े कुछ संसाधन इस तरह से कॉन्फ़िगर किए गए हों कि वे एपीआई प्रॉक्सी कॉन्फ़िगरेशन में स्टैटिक बने रहें.

• टारगेट यूआरएल: एपीआई प्रॉक्सी के लिए, टेस्टिंग और प्रोडक्शन के दौरान अलग-अलग बैकएंड यूआरएल को कॉल करना आम बात है. TargetServer कॉन्फ़िगरेशन का इस्तेमाल करके, एनवायरमेंट से अलग TargetEndpoint कॉन्फ़िगरेशन बनाए जा सकते हैं. बैकएंड सर्वर के बीच लोड बैलेंसिंग लेख पढ़ें.
• कैश और कुंजी/वैल्यू वाले मैप: दोनों परसिस्टेंस रिसॉर्स, एनवायरमेंट के हिसाब से तय किए जाते हैं. आपको यह पक्का करना चाहिए कि नाम रखने के नियमों का इस्तेमाल किया गया हो, ताकि एपीआई प्रॉक्सी, डेटा को सेव कर सकें. इसके लिए, प्रमोशन के दौरान कॉन्फ़िगरेशन में बदलाव करने की ज़रूरत न पड़े. एनवायरमेंट कैश मेमोरी बनाना और उसमें बदलाव करना लेख पढ़ें.
• ServiceCallout के टारगेट: ServiceCallout, एनवायरमेंट के हिसाब से अलग-अलग टारगेट का इस्तेमाल कर सकते हैं. उदाहरण के लिए, अगर टेस्ट एनवायरमेंट में मौजूद कोई ServiceCallout, डेमो सेवा का इस्तेमाल करता है. सेवा कॉलआउट एक्सटेंशन से जुड़ी नीति देखें.

एपीआई प्रॉक्सी कॉन्फ़िगरेशन को एनवायरमेंट से अलग करने के लिए, शर्त वाले स्टेटमेंट का भी इस्तेमाल किया जा सकता है. environment.name वैरिएबल का इस्तेमाल करके बनाया गया कंडीशनल स्टेटमेंट, मौजूदा एनवायरमेंट का आकलन करने के लिए इस्तेमाल किया जा सकता है. ऐसा किसी नीति को लागू करने से पहले या बैकएंड पर किसी यूआरएल पर रीडायरेक्ट करने से पहले किया जा सकता है.

ज़्यादा जानकारी के लिए, डिप्लॉयमेंट के बारे में जानकारी लेख पढ़ें.