आपको Apigee Edge दस्तावेज़ दिख रहा है.
Apigee X दस्तावेज़ देखें.
हर संगठन के सॉफ़्टवेयर डेवलपमेंट का एक यूनीक लाइफ़साइकल (एसडीएलसी) होता है. अक्सर यह ज़रूरी होता है कि एपीआई प्रॉक्सी डिप्लॉयमेंट को बैकएंड सेवाओं के लिए इस्तेमाल की जाने वाली प्रोसेस के साथ सिंक और अलाइन किया जाए.
इस विषय में एज एपीआई के तरीकों का इस्तेमाल, आपके संगठन के एसडीएलसी में एपीआई प्रॉक्सी मैनेजमेंट को इंटिग्रेट करने के लिए किया जा सकता है. इस एपीआई का सामान्य इस्तेमाल ऐसी स्क्रिप्ट या कोड लिखने के लिए किया जाता है जो एपीआई प्रॉक्सी को डिप्लॉय करता है. यह एक बड़ी ऑटोमेटेड प्रोसेस के हिस्से के तौर पर एक प्रॉक्सी से दूसरे एनवायरमेंट में एपीआई प्रॉक्सी माइग्रेट करता है, जो अन्य ऐप्लिकेशन को भी डिप्लॉय या माइग्रेट करता है.
Edge API, आपके एसडीएलसी (या किसी और के लिए) के बारे में कोई अनुमान नहीं लगाता है. इसके बजाय, यह ऐसे एटॉमिक फ़ंक्शन को दिखाता है जिन्हें आपकी डेवलपमेंट टीम, साथ ही, आपके एपीआई डेवलपमेंट की लाइफ़साइकल को ऑटोमेट और ऑप्टिमाइज़ कर सकती है.
पूरी जानकारी के लिए, Edge API देखें.
Edge एपीआई का इस्तेमाल करने के लिए, आपको अपने कॉल में खुद की पुष्टि करनी होगी. ऐसा करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:
- OAuth2 (सिर्फ़ सार्वजनिक क्लाउड)
- एसएएमएल (सार्वजनिक और निजी क्लाउड)
- सामान्य पुष्टि करना (इसका सुझाव नहीं दिया जाता है; सार्वजनिक और निजी क्लाउड)
यह विषय एपीआई के सेट पर फ़ोकस करता है, जो एपीआई प्रॉक्सी को मैनेज करने के लिए हैं.
वीडियो: एपीआई को डिप्लॉय करने का तरीका जानने के लिए, यह छोटा वीडियो देखें.
एपीआई के साथ इंटरैक्ट करना
इन चरणों की मदद से, एपीआई के साथ सामान्य इंटरैक्शन की जानकारी दी जा सकती है.
अपने संगठन में एपीआई की सूची बनाएं
आप अपने संगठन में सभी API प्रॉक्सी सूचीबद्ध करके शुरुआत कर सकते हैं. EMAIL:PASSWORD और ORG_NAME के लिए एंट्री को बदलना न भूलें. निर्देशों के लिए, EDGE API का इस्तेमाल करना देखें.
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis
जवाब का नमूना:
[ "weatherapi" ]
एपीआई पाएं
आप अपने संगठन में किसी भी एपीआई प्रॉक्सी पर GET
तरीके को कॉल कर सकते हैं. इस कॉल में एपीआई प्रॉक्सी के सभी उपलब्ध बदलावों की सूची दिखती है.
curl -u EMAIL:PASSWORD -H "Accept: application/json" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi
जवाब का नमूना:
{ "name" : "weatherapi", "revision" : [ "1" ] }
इस तरीके से सिर्फ़ एपीआई की प्रॉक्सी के नाम के बारे में पता चलता है. साथ ही, इस एपीआई से जुड़ी बदलाव की जानकारी भी होती है. एपीआई प्रॉक्सी में कॉन्फ़िगरेशन फ़ाइलों का बंडल शामिल होता है. बदलावों को लागू करने के बाद, आप कॉन्फ़िगरेशन से जुड़े अपडेट को आसानी से मैनेज कर सकते हैं. बदलावों को क्रम से लगाया गया है, जिससे आप अपने एपीआई प्रॉक्सी के पिछले बदलाव को डिप्लॉय करके, बदलाव को पहले जैसा कर सकते हैं. साथ ही, एपीआई एनवायरमेंट में एपीआई प्रॉक्सी में बदलाव को लागू किया जा सकता है. साथ ही, जांच के माहौल में उस एपीआई प्रॉक्सी में नए बदलाव किए जा सकते हैं. जब आप तैयार हो जाएं, तो प्रोडक्शन एनवायरमेंट में एपीआई प्रॉक्सी के पिछले वर्शन के बजाय, टेस्ट एनवायरमेंट में अपने एपीआई प्रॉक्सी के ज़्यादा वर्शन का प्रमोशन किया जा सकता है.
इस उदाहरण में, सिर्फ़ एक बदलाव किया गया है, क्योंकि एपीआई प्रॉक्सी को अभी-अभी बनाया गया है. एपीआई प्रॉक्सी का इस्तेमाल करके बार-बार दोहराए जाने वाले कॉन्फ़िगरेशन और डिप्लॉयमेंट की प्रोसेस पूरी हो जाती है. इस वजह से, बदलाव की संख्या में इंटीजर बढ़ जाता है. डिप्लॉय करने के लिए डायरेक्ट एपीआई कॉल का इस्तेमाल करके, वैकल्पिक रूप से एपीआई प्रॉक्सी की बदलाव की संख्या बढ़ाई जा सकती है. कभी-कभी जब आप छोटे बदलाव करते हैं, तो हो सकता है कि आप उनमें बदलाव न करना चाहें.
एपीआई रिविज़न कराना
एपीआई के वर्शन (उदाहरण के लिए, api.company.com/v1
) में बहुत कम बदलाव होने चाहिए. एपीआई वर्शन को बढ़ाने का मतलब है कि डेवलपर को यह पता चलता है कि एपीआई के ज़रिए दिखाए गए बाहरी इंटरफ़ेस के हस्ताक्षर में काफ़ी बदलाव हुआ है.
एपीआई प्रॉक्सी रिवीज़न एक बढ़ी हुई संख्या है, जो एपीआई प्रॉक्सी कॉन्फ़िगरेशन से जुड़ा होता है. एपीआई सेवाएं, आपके कॉन्फ़िगरेशन में कुछ बदलाव करती हैं, ताकि कोई गड़बड़ी होने पर
आप कॉन्फ़िगरेशन को वापस कर सकें. डिफ़ॉल्ट रूप से, जब भी एपीआई प्रॉक्सी इंपोर्ट करें एपीआई का इस्तेमाल करके, एपीआई प्रॉक्सी को इंपोर्ट किया जाता है, तो एपीआई प्रॉक्सी का वर्शन अपने-आप बढ़ता है. अगर
आपको एपीआई प्रॉक्सी का वर्शन नहीं बढ़ाना है, तो एपीआई प्रॉक्सी
अपडेट को अपडेट करें एपीआई का इस्तेमाल करें. अगर आपने डिप्लॉय करने के लिए मेवन का इस्तेमाल किया है, तो Maven प्लग इन रीडमी में बताए गए तरीके से clean
या update
विकल्प का इस्तेमाल करें.
उदाहरण के लिए, व्यू की पूरी जानकारी पाने के लिए, एपीआई प्रॉक्सी वर्शन 1 पर GET
तरीके को कॉल किया जा सकता है.
curl -u EMAIL:PASSWORD -H "Accept:application/json" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1
जवाब का नमूना
{ "configurationVersion" : { "majorVersion" : 4, "minorVersion" : 0 }, "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}", "createdAt" : 1343178905169, "createdBy" : "andrew@apigee.com", "lastModifiedAt" : 1343178905169, "lastModifiedBy" : "andrew@apigee.com", "name" : "weatherapi", "policies" : [ ], "proxyEndpoints" : [ ], "resources" : [ ], "revision" : "1", "targetEndpoints" : [ ], "targetServers" : [ ], "type" : "Application" }
इन एपीआई प्रॉक्सी कॉन्फ़िगरेशन एलिमेंट को एपीआई प्रॉक्सी कॉन्फ़िगरेशन रेफ़रंस में बेहतर तरीके से समझाया गया है.
एपीआई को किसी एनवायरमेंट में डिप्लॉय करना
जब आपका एपीआई प्रॉक्सी सही तरीके से अनुरोध पाने और उन्हें फ़ॉरवर्ड करने के लिए कॉन्फ़िगर हो जाए, तो इसे एक या एक से ज़्यादा एनवायरमेंट में डिप्लॉय किया जा सकता है. आम तौर पर, एपीआई प्रॉक्सी में बार-बार इस्तेमाल किया जाता है. इसके बाद, जब भी तैयार हो, आपके पास एपीआई प्रॉक्सी में prod
बदलाव करने का प्रमोशन होता है.test
आम तौर पर, आपको लगता है कि जांच वाले माहौल में आपके लिए एपीआई प्रॉक्सी में कई और बदलाव किए गए हैं. ऐसा इसलिए किया जाता है, क्योंकि prod परिवेश में आपको और भी कम बदलाव करने पड़ते हैं.
एपीआई प्रॉक्सी को तब तक शुरू नहीं किया जा सकता, जब तक कि उसे किसी एनवायरमेंट में डिप्लॉय नहीं कर दिया जाता. एपीआई प्रॉक्सी में बदलाव करने के बाद, उसे प्रोडक्शन में डिप्लॉय करने के बाद, बाहरी यूआरएल को prod
डेवलपर के लिए पब्लिश किया जा सकता है.
एनवायरमेंट की सूची बनाने का तरीका
Apigee Edge में मौजूद हर संगठन के कम से कम दो एनवायरमेंट होते हैं: test
और prod
. फ़र्क़ को मनमाने तरीके से इस्तेमाल किया जा सकता है. हमारा मकसद आपको यह पता लगाने के लिए एक सेक्शन उपलब्ध कराना है कि आपका एपीआई प्रॉक्सी काम कर रहा है या नहीं. इसके बाद ही, किसी बाहरी डेवलपर को इसे खोलने की अनुमति मिलेगी.
हर एनवायरमेंट असल में एक नेटवर्क पता होता है. इससे आपको उन एपीआई प्रॉक्सी के बीच ट्रैफ़िक को अलग करने में मदद मिलती है जिन पर आप काम कर रहे हैं और जिन्हें रनटाइम के दौरान ऐप्लिकेशन ऐक्सेस कर रहे हैं.
एनवायरमेंट, डेटा और संसाधनों को अलग-अलग करने में भी मदद करते हैं. उदाहरण के लिए, जांच और प्रोड्यूस में अलग-अलग कैश मेमोरी सेट अप की जा सकती है. इसे सिर्फ़ एपीआई प्रॉक्सी के ज़रिए ऐक्सेस किया जा सकता है जो उस एनवायरमेंट में काम करता है.
किसी संगठन में माहौल देखना
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments
रिस्पॉन्स का उदाहरण
[ "test", "prod" ]
डिप्लॉयमेंट के बारे में जानें
डिप्लॉयमेंट, किसी एपीआई प्रॉक्सी का ऐसा वर्शन है जिसे किसी एनवायरमेंट में डिप्लॉय किया गया है. प्रॉक्सी वाली स्थिति में मौजूद एपीआई प्रॉक्सी को नेटवर्क पर ऐक्सेस किया जा सकता है. यह ऐक्सेस उस एनवायरमेंट के लिए <VirtualHost>
एलिमेंट में दिए गए पतों पर होता है.
डिप्लॉय होने वाले एपीआई प्रॉक्सी
एपीआई प्रॉक्सी को तब तक लागू नहीं किया जा सकता, जब तक कि उन्हें डिप्लॉय न कर लिया जाए. एपीआई सेवाएं, RESTful API को दिखाती हैं जो डिप्लॉयमेंट की प्रोसेस को कंट्रोल करता है.
किसी दिए गए समय में, एपीआई प्रॉक्सी में सिर्फ़ एक ही बदलाव को किसी एनवायरमेंट में लागू किया जा सकता है. इसलिए, लागू किए गए बदलावों को डिप्लॉय नहीं करना चाहिए. आपके पास यह कंट्रोल करने का विकल्प होता है कि नए बंडल को नए वर्शन के तौर पर डिप्लॉय किया जाए या नहीं. साथ ही, यह भी कंट्रोल किया जा सकता है कि वह मौजूदा वर्शन को ओवरराइट करता है या नहीं.
आपको Apigee Edge दस्तावेज़ दिख रहा है.
Apigee X दस्तावेज़ देखें.
पहले, मौजूदा वर्शन को डिप्लॉय न करें. एनवायरमेंट के नाम और उस एपीआई प्रॉक्सी के रिवीज़न नंबर की जानकारी दें जिसे आपको डिप्लॉय नहीं करना है:
curl -X DELETE \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \ -u EMAIL:PASSWORD
इसके बाद, नए बदलाव को डिप्लॉय करें. एपीआई प्रॉक्सी का नया वर्शन पहले से मौजूद होना चाहिए:
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \ -u EMAIL:PASSWORD
आसान डिप्लॉयमेंट (शून्य डाउनटाइम)
डिप्लॉयमेंट के दौरान डाउनटाइम की संभावना को कम करने के लिए, डिप्लॉयमेंट के तरीके पर override
पैरामीटर का इस्तेमाल करें और इसे true
पर सेट करें.
आप किसी API प्रॉक्सी के एक संशोधन को दूसरे के ऊपर परिनियोजित नहीं कर सकते. सबसे पहले हमेशा
डिप्लॉय नहीं किया जाना चाहिए. override
को true
पर सेट करके, आप यह बताते हैं कि एपीआई प्रॉक्सी का एक बदलाव, लागू किए गए मौजूदा बदलाव के बाद लागू होना चाहिए. इसका नतीजा यह होता है कि
डिप्लॉयमेंट क्रम उलटा होता है--नए वर्शन को डिप्लॉय किया जाता है और
डिप्लॉयमेंट पूरा हो जाने के बाद, पहले से डिप्लॉय किए गए बदलाव को डिप्लॉय नहीं किया जाता है.
इस उदाहरण में, override
पैरामीटर को फ़ॉर्म पैरामीटर के तौर पर पास करके सेट किया गया है:
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \ -d "override=true" \ -u EMAIL:PASSWORD
delay
पैरामीटर सेट करके, डिप्लॉयमेंट को ऑप्टिमाइज़ किया जा सकता है. delay
पैरामीटर, समय अंतराल के बारे में बताता है. इससे पहले, पिछले बदलावों को लागू नहीं किया जा सकता. इसका असर यह होता है कि इन-फ़्लाइट लेन-देन की अवधि, एपीआई प्रॉक्सी की प्रोसेसिंग से पहले पूरी की जाती है. इस दौरान, लेन-देन को डिप्लॉय नहीं किया जाता. यहां बताया गया है कि
override=true
और delay
पैरामीटर सेट के साथ क्या होता है:
- बदलाव 1, अनुरोधों को हैंडल कर रहा है.
- बदलाव 2 को एक साथ डिप्लॉय किया जा रहा है.
- जब बदलाव 2 पूरी तरह से लागू हो जाता है, तब बदलाव 2 को नया ट्रैफ़िक भेजा जाता है. बदलाव 1 के लिए कोई नया ट्रैफ़िक नहीं भेजा जाता है.
- हालांकि, हो सकता है कि बदलाव 1 मौजूदा लेन-देन की प्रक्रिया पूरी कर रहा हो.
delay
पैरामीटर (उदाहरण के लिए, 15 सेकंड) सेट करके, मौजूदा लेन-देन को प्रोसेस करने के लिए बदलाव करने का समय 1 15 सेकंड है. - देरी के बाद वाले समय के बाद, बदलाव 1 को लागू नहीं किया जाता.
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \ -d "override=true" \ -u EMAIL:PASSWORD
क्वेरी पैरामीटर | जानकारी |
---|---|
override |
डिफ़ॉल्ट तौर पर, सामान्य डिप्लॉयमेंट की प्रोसेस को बदलने के लिए |
delay |
इस्तेमाल न किए जाने से पहले, लेन-देन की प्रोसेसिंग को मौजूदा वर्शन पर पूरा करने और
डिफ़ॉल्ट संख्या 0 (शून्य) सेकंड है. जब |
जब delay
के साथ override=true
का इस्तेमाल किया जाता है, तो डिप्लॉयमेंट के दौरान एचटीटीपी 5XX
के
रिस्पॉन्स को हटाया जा सकता है. ऐसा इसलिए होगा, क्योंकि एपीआई प्रॉक्सी के दोनों बदलाव एक साथ लागू होंगे. साथ ही, देरी के बाद, पुराने बदलाव को लागू नहीं किया जाएगा.
एपीआई रिविज़न के सभी डिप्लॉयमेंट देखें
कभी-कभी एपीआई प्रॉक्सी के लागू किए गए सभी मौजूदा बदलावों की सूची पाना ज़रूरी होता है.
curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \ -u EMAIL:PASSWORD
{ "aPIProxy" : "weatherapi", "environment" : [ { "configuration" : { "basePath" : "", "steps" : [ ] }, "name" : "test", "server" : [ { "status" : "deployed", "type" : [ "message-processor" ], "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200" }, { "status" : "deployed", "type" : [ "message-processor" ], "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549" }, { "status" : "deployed", "type" : [ "router" ], "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805" }, { "status" : "deployed", "type" : [ "router" ], "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8" } ], "state" : "deployed" } ], "name" : "1", "organization" : "org_name" }
ऊपर दिए गए जवाब में Apigee Edge की अंदरूनी संरचना के लिए खास तौर पर कई प्रॉपर्टी हैं. जब तक कंपनी की इमारत में Apigee एज का इस्तेमाल नहीं किया जाता, तब तक इन सेटिंग में बदलाव नहीं किया जा सकता.
जवाब में शामिल मुख्य प्रॉपर्टी organization
, environment
, aPIProxy
, name
, और state
हैं. प्रॉपर्टी की इन वैल्यू की समीक्षा करके, यह पुष्टि की जा सकती है कि एपीआई प्रॉक्सी का खास बदलाव किसी एनवायरमेंट में लागू किया गया है.
टेस्ट एनवायरमेंट में सभी डिप्लॉयमेंट देखें
नीचे दिए गए कॉल का इस्तेमाल करके, किसी खास एनवायरमेंट (जो फ़िलहाल लागू किए गए एपीआई प्रॉक्सी की बदलाव संख्या शामिल है) के लिए डिप्लॉयमेंट की स्थिति को भी वापस लाया जा सकता है:
curl -u EMAIL:PASSWORD https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments
इससे, टेस्ट एनवायरमेंट में डिप्लॉय किए गए हर एपीआई के लिए ऊपर बताए गए तरीके से नतीजे मिलते हैं
अपने संगठन में सभी डिप्लॉयमेंट की जानकारी देखें
सभी एनवायरमेंट में, सभी एपीआई प्रॉक्सी के लागू किए गए मौजूदा बदलावों की सूची फ़ेच करने के लिए, एपीआई के इस तरीके का इस्तेमाल करें:
curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \ -u EMAIL:PASSWORD
इससे, सभी एनवायरमेंट में डिप्लॉय किए गए सभी एपीआई प्रॉक्सी के लिए, ऊपर दिए गए तरीके का इस्तेमाल किया जा सकता है.
एपीआई एक RESTful है, इसलिए आपको एपीआई प्रॉक्सी बनाने के लिए, उसी रिसॉर्स के मुकाबले JSON या एक्सएमएल पेलोड के साथ-साथ, POST
तरीके का इस्तेमाल करना होगा.
आपके एपीआई प्रॉक्सी के लिए प्रोफ़ाइल जनरेट की जाती है. JavaScript प्रॉक्सी का डिफ़ॉल्ट वर्शन, JavaScript ऑब्जेक्ट नोटेशन (JSON) में होता है. यह ऊपर दिए गए POST
अनुरोध के लिए डिफ़ॉल्ट JSON रिस्पॉन्स है.
इसकी वजह से weatherapi
नाम का एपीआई प्रॉक्सी बन गया है. प्रोफ़ाइल में मौजूद हर एलिमेंट का ब्यौरा:
{ "configurationVersion" : { "majorVersion" : 4, "minorVersion" : 0 }, "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}", "createdAt" : 1357172145444, "createdBy" : "you@yourcompany.com", "displayName" : "weatherapi", "lastModifiedAt" : 1357172145444, "lastModifiedBy" : "you@yourcompany.com", "name" : "weatherapi", "policies" : [ ], "proxyEndpoints" : [ ], "resources" : [ ], "revision" : "1", "targetEndpoints" : [ ], "targetServers" : [ ], "type" : "Application" }
जनरेट की जाने वाली एपीआई प्रॉक्सी प्रोफ़ाइल, एपीआई प्रॉक्सी का पूरा स्ट्रक्चर दिखाती है:
APIProxy revision
: एपीआई प्रॉक्सी कॉन्फ़िगरेशन की क्रम में चलने वाली संख्या, जिसमें एपीआई सेवाओं का रखरखाव होता हैAPIProxy name
, एपीआई प्रॉक्सी का यूनीक नामConfigurationVersion
: एपीआई सेवाओं का वह वर्शन जो एपीआई प्रॉक्सी कॉन्फ़िगरेशन के मुताबिक होता हैCreatedAt
: वह समय जब एपीआई प्रॉक्सी जनरेट की गई, यूनिक्स समय में फ़ॉर्मैट किया गयाCreatedBy
: उस Apigee Edge उपयोगकर्ता का ईमेल पता जिसने एपीआई प्रॉक्सी बनायाDisplayName
: API प्रॉक्सी के लिए उपयोगकर्ता के अनुकूल नामLastModifiedAt
: वह समय जब एपीआई प्रॉक्सी जनरेट की गई. यह यूनिक्स टाइम में फ़ॉर्मैट किया गयाLastModifiedBy
: उस Apigee Edge उपयोगकर्ता का ईमेल पता जिसने एपीआई प्रॉक्सी बनायाPolicies
, इस एपीआई प्रॉक्सी में जोड़ी गई नीतियों की सूचीProxyEndpoints
ProxyEndpoints की सूचीResources
, इस एपीआई प्रॉक्सी में एक्ज़ीक्यूट करने के लिए उपलब्ध रिसॉर्स (JavaScript, Python, Java, XSLT) की सूचीTargetServers
, टारगेट सर्वर की सूची (जिसे मैनेजमेंट एपीआई का इस्तेमाल करके बनाया जा सकता है), इसका इस्तेमाल लोड बैलेंसिंग के लिए बेहतर कॉन्फ़िगरेशन में किया जाता हैTargetEndpoints
: टारगेट एंडपॉइंट के नाम की सूची
ध्यान दें कि ऊपर दिए गए आसान POST
तरीके का इस्तेमाल करके, बनाए गए एपीआई प्रॉक्सी कॉन्फ़िगरेशन के कई एलिमेंट खाली हैं. नीचे दिए गए विषयों में, आपको एपीआई प्रॉक्सी के मुख्य कॉम्पोनेंट को जोड़ने और कॉन्फ़िगर करने का तरीका पता चलेगा.
एपीआई प्रॉक्सी कॉन्फ़िगरेशन के रेफ़रंस में, इन कॉन्फ़िगरेशन एलिमेंट के बारे में भी पढ़ा जा सकता है.
एपीआई की मदद से स्क्रिप्ट लिखना
GitHub पर सैंपल एपीआई प्रॉक्सी का इस्तेमाल करके, शेल स्क्रिप्ट उपलब्ध कराई जाती हैं, जो Apigee डिप्लॉयमेंट टूल को रैप करती हैं. अगर किसी वजह से आप Python डिप्लॉयमेंट टूल का इस्तेमाल नहीं कर पा रहे हैं, तो आप सीधे एपीआई को कॉल करें. दोनों तरीकों को सैंपल स्क्रिप्ट में दिखाया गया है.
डिप्लॉयमेंट टूल रैप करें
सबसे पहले, पक्का करें कि आपके स्थानीय माहौल में Python डिप्लॉयमेंट टूल उपलब्ध हो.
इसके बाद, अपने क्रेडेंशियल होल्ड करने के लिए कोई फ़ाइल बनाएं. आपने जो डिप्लॉयमेंट स्क्रिप्ट लिखी हैं वे इन सेटिंग को इंपोर्ट कर पाएंगी. इससे, आपको अपने खाते के क्रेडेंशियल को एक ही जगह से मैनेज करने में मदद मिलेगी. एपीआई
प्लैटफ़ॉर्म के सैंपल में, इस फ़ाइल को setenv.sh
कहा जाता है.
#!/bin/bash org="Your ORG on enterprise.apigee.com" username="Your USERNAME on enterprise.apigee.com" # While testing, it's not necessary to change the setting below env="test" # Change the value below only if you have an on-premise deployment url="https://api.enterprise.apigee.com" # Change the value below only if you have a custom domain api_domain="apigee.net" export org=$org export username=$username export env=$env export url=$url export api_domain=$api_domain
ऊपर दी गई फ़ाइल, परिनियोजन स्क्रिप्ट को रैप करने वाली शेल स्क्रिप्ट के लिए आपकी सभी सेटिंग उपलब्ध कराती है.
अब एक ऐसी शेल स्क्रिप्ट बनाएं जो उन सेटिंग को इंपोर्ट करे और डिप्लॉय टूल को कॉल करने के लिए उनका इस्तेमाल करे. (उदाहरण के लिए, Apigee API प्लैटफ़ॉर्म के सैंपल देखें.)
#!/bin/bash source path/to/setenv.sh echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:" read -s password echo Deploying $proxy to $env on $url using $username and $org path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy
एपीआई को इस्तेमाल करने और उसकी जांच करने के लिए, स्क्रिप्ट बनाने का तरीका यहां दिया गया है:
#!/bin/bash echo Using org and environment configured in /setup/setenv.sh source /path/to/setenv.sh set -x curl "http://$org-$env.apigee.net/{api_basepath}"
एपीआई का सीधे तौर पर स्वागत करना
यह आसानी से शेल स्क्रिप्ट लिखने में मदद कर सकता है, जो एपीआई प्रॉक्सी और अपलोड की प्रक्रिया को ऑटोमेट करती है.
नीचे दी गई स्क्रिप्ट, मैनेजमेंट एपीआई को सीधे तौर पर शुरू करती है. आप जिस एपीआई प्रॉक्सी को अपडेट कर रहे हैं
उसके मौजूदा वर्शन को डिप्लॉय नहीं करता है. यह आपकी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों वाली /apiproxy
डायरेक्ट्री से एक ZIP फ़ाइल बनाता है.
इसके बाद, यह कॉन्फ़िगरेशन अपलोड, इंपोर्ट, और डिप्लॉय करता है.
#!/bin/bash #This sets the name of the API proxy and the basepath where the API will be available api=api source /path/to/setenv.sh echo Delete the DS_store file on OSX echo find . -name .DS_Store -print0 | xargs -0 rm -rf find . -name .DS_Store -print0 | xargs -0 rm -rf echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:" read -s password echo Undeploy and delete the previous revision # Note that you need to explicitly update the revision to be undeployed. # One benefit of the Python deploy tool is that it manages this for you. curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1" rm -rf $api.zip echo Create the API proxy bundle and deploy zip -r $api.zip apiproxy echo Import the new revision to $env environment curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST echo Deploy the new revision to $env environment curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST