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

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

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

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

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

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

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

• OAuth2 (सिर्फ़ सार्वजनिक क्लाउड के लिए)
• SAML (सार्वजनिक और निजी क्लाउड)
• बुनियादी पुष्टि (इसका सुझाव नहीं दिया जाता; सार्वजनिक और निजी क्लाउड)

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

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

एपीआई का इस्तेमाल करना

नीचे दिए गए तरीके से, आपको एपीआई का इस्तेमाल करके आसान इंटरैक्शन के बारे में जानकारी मिलेगी.

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

अपने संगठन में सभी एपीआई प्रॉक्सी को सूची में शामिल करके शुरुआत की जा सकती है. (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) को कभी-कभी बदला जाना चाहिए. एपीआई वर्शन को बढ़ाने पर, डेवलपर को यह पता चलता है कि एपीआई ने जिस बाहरी इंटरफ़ेस को दिखाया है उसके सिग्नेचर में काफ़ी बदलाव हुआ है.

एपीआई प्रॉक्सी बदलाव एक बढ़ी हुई संख्या है जो एपीआई प्रॉक्सी कॉन्फ़िगरेशन से जुड़ी होती है. API सेवाएं आपके कॉन्फ़िगरेशन में बदलाव करती हैं, ताकि कुछ गलत होने पर कॉन्फ़िगरेशन को पहले जैसा किया जा सके. डिफ़ॉल्ट रूप से, जब भी एपीआई प्रॉक्सी इंपोर्ट करें एपीआई का इस्तेमाल करके कोई एपीआई प्रॉक्सी इंपोर्ट किया जाता है, तो एपीआई प्रॉक्सी का रिविज़न अपने-आप बढ़ जाता है. अगर आपको एपीआई प्रॉक्सी में हुए बदलावों को नहीं बढ़ाना है, तो Update API प्रॉक्सी संशोधन एपीआई का इस्तेमाल करें. अगर डिप्लॉय करने के लिए Maven का इस्तेमाल किया जा रहा है, तो clean या update विकल्पों का इस्तेमाल करें, जैसा कि Maven प्लगिन रीडमी में बताया गया है.

उदाहरण के लिए, एपीआई प्रॉक्सी वर्शन 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"
}

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

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

एपीआई प्रॉक्सी को सही तरीके से पाने और फ़ॉरवर्ड करने के लिए कॉन्फ़िगर किए जाने के बाद, उसे एक या एक से ज़्यादा एनवायरमेंट में डिप्लॉय किया जा सकता है. आम तौर पर, 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 पर सेट होती है, तो नया वर्शन लागू होने के तुरंत बाद, मौजूदा बदलाव लागू नहीं होता है. नेगेटिव वैल्यू को 0 (शून्य) सेकंड माना जाता है.

जब override=true को delay के साथ इस्तेमाल किया जाता है, तो डिप्लॉयमेंट के दौरान एचटीटीपी 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 Edge का ऑन-प्रिमाइस इस्तेमाल नहीं किया जा रहा है, तब तक इन सेटिंग को नहीं बदला जा सकता.

जवाब में शामिल अहम प्रॉपर्टी 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 ऑब्जेक्ट नोटेशन (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: एपीआई प्रॉक्सी जनरेट करने का समय, जिसे UNIX समय में फ़ॉर्मैट किया गया है
• CreatedBy: उस Apigee Edge उपयोगकर्ता का ईमेल पता जिसने एपीआई प्रॉक्सी बनाया था
• DisplayName: एपीआई प्रॉक्सी के लिए उपयोगकर्ता के लिए आसान नाम
• LastModifiedAt: एपीआई प्रॉक्सी जनरेट होने का समय, जो UNIX समय में फ़ॉर्मैट किया गया है
• LastModifiedBy: उस Apigee Edge उपयोगकर्ता का ईमेल पता जिसने एपीआई प्रॉक्सी बनाया था
• Policies: इस एपीआई प्रॉक्सी में जोड़ी गई नीतियों की सूची
• ProxyEndpoints: नाम वाले प्रॉक्सीEndpoints की सूची
• Resources: इस एपीआई प्रॉक्सी में चलाने के लिए उपलब्ध संसाधनों की सूची (JavaScript, Python, Java, XSLT)
• TargetServers: नाम के टारगेटसर्वर (जो मैनेजमेंट एपीआई की मदद से बनाए जा सकते हैं) की सूची, जिसका इस्तेमाल लोड बैलेंस करने के लिए बेहतर कॉन्फ़िगरेशन में इस्तेमाल किया जाता है
• TargetEndpoints: 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