एपीआई का इस्तेमाल करके, प्रॉक्सी को डिप्लॉय करें

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

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

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

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

पूरी जानकारी के लिए, Edge API देखें.

Edge एपीआई का इस्तेमाल करने के लिए, आपको अपने कॉल में खुद की पुष्टि करनी होगी. ऐसा करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:

यह विषय एपीआई के सेट पर फ़ोकस करता है, जो एपीआई प्रॉक्सी को मैनेज करने के लिए हैं.

वीडियो: एपीआई को डिप्लॉय करने का तरीका जानने के लिए, यह छोटा वीडियो देखें.

एपीआई के साथ इंटरैक्ट करना

इन चरणों की मदद से, एपीआई के साथ सामान्य इंटरैक्शन की जानकारी दी जा सकती है.

अपने संगठन में एपीआई की सूची बनाएं

आप अपने संगठन में सभी 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

डिफ़ॉल्ट तौर पर, false का इस्तेमाल किया जाता है (डिप्लॉयमेंट का सामान्य तरीका: मौजूदा वर्शन को डिप्लॉय नहीं किया गया है, फिर नया वर्शन लागू किया गया है).

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

इस्तेमाल न किए जाने से पहले, लेन-देन की प्रोसेसिंग को मौजूदा वर्शन पर पूरा करने और 502 Bad Gateway या 504 Gateway Timeout errors की संभावना हटाने के लिए—इस पैरामीटर को उतने सेकंड के लिए सेट करें जितने समय के लिए डिप्लॉयमेंट में देरी हो. जितने चाहें उतने सेकंड सेट किए जा सकते हैं. साथ ही, बहुत बड़ी संख्या में सेकंड सेट करने से जुड़ी परफ़ॉर्मेंस पर कोई असर नहीं पड़ता है. देरी के दौरान, पुराने वर्शन में कोई नया ट्रैफ़िक नहीं भेजा जाता.

डिफ़ॉल्ट संख्या 0 (शून्य) सेकंड है. जब 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