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

आपको Apigee Edge दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं.
जानकारी

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

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

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

एपीआई एनवायरमेंट और एपीआई डेवलपमेंट की लाइफ़साइकल के बारे में जानने के लिए यह वीडियो देखें.

एनवायरमेंट

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

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

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

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

टेस्ट में बार-बार डेवलपमेंट

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

प्रमोशन को प्रॉडक्ट में बदलना

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

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

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

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

एनवायरमेंट से जुड़े संसाधन

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

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

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

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

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