एपीआई प्रॉक्सी कॉन्फ़िगरेशन के बारे में जानकारी

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

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

अगर आपको एपीआई प्रॉक्सी बनाने का तरीका सीखना है, तो हमारा सुझाव है कि आप कोई आसान एपीआई बनाएं प्रॉक्सी पर टैप करें.

प्रॉक्सी कॉन्फ़िगरेशन में बदलाव करने के सबसे सामान्य तरीके ये हैं:

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

प्रॉक्सी कॉन्फ़िगरेशन का लोकल डेवलपमेंट

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

इस सेक्शन में बताया गया है कि मौजूदा प्रॉक्सी कंफ़र्शन को डाउनलोड करने, उसमें बदलाव करने, और और फिर डिप्लॉयमेंट के लिए इसे Edge पर वापस अपलोड करें. Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए पिजी टूल नया प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड और डिप्लॉय करने के लिए, (fetchproxy और deployproxy निर्देश.)

यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, प्रॉक्सी कॉन्फ़िगरेशन में बदलाव करने के लिए:

1. Edge के यूज़र इंटरफ़ेस (यूआई) में मौजूदा प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड करें. (एपीआई प्रॉक्सी में देखें, प्रोजेक्ट > बदलाव डाउनलोड करें.)
2. अपनी लोकल मशीन पर, एक नई डायरेक्ट्री बनाएं और डाउनलोड की गई ZIP फ़ाइल को इसे.

   ZIP फ़ाइल को बड़ा करने के लिए, unzip जैसी सुविधा का इस्तेमाल करें. इसके लिए, नीचे दिए गए तरीके अपनाएं उदाहरण में यह दिखाया गया है:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

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

3. ज़रूरत के मुताबिक सोर्स फ़ाइलों में बदलाव करें. प्रॉक्सी में सोर्स फ़ाइलों की जानकारी के लिए कॉन्फ़िगरेशन, देखें कॉन्फ़िगरेशन फ़ाइलें और एपीआई प्रॉक्सी का डायरेक्ट्री स्ट्रक्चर.

   उदाहरण के लिए, हेल्थ मॉनिटरिंग अपना एपीआई प्रॉक्सी बनाने के लिए, /apiproxy/targets/ डायरेक्ट्री. इस डायरेक्ट्री में डिफ़ॉल्ट फ़ाइल यह है default.xml, हालांकि, इस्तेमाल करने पर अलग-अलग नामों वाली फ़ाइलें हो सकती हैं कंडिशनल टारगेट.

   इस मामले में, अगर TargetEndpoint कॉन्फ़िगरेशन फ़ाइल और उसकी डायरेक्ट्री मौजूद नहीं है, उन्हें बना सकता है.

4. प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने के बाद, अपने बदलावों को सेव करना न भूलें.
5. ZIP फ़ाइलों को बड़ा करते समय बनाई गई नई डायरेक्ट्री में बदलें (मूल फ़ाइल) कॉन्फ़िगरेशन फ़ाइलें बढ़ाई जा सकती हैं.

   उदाहरण के लिए, अगर आपने फ़ाइलों को /myappdir डायरेक्ट्री में बड़ा किया है, तो इसमें बदलें जैसा कि नीचे दिए गए उदाहरण में बताया गया है:

   cd myappdir

   अपनी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों को फिर से संग्रहित करने से पहले, आपको इस डायरेक्ट्री को इस्तेमाल करना होगा क्योंकि आप /myappdir डायरेक्ट्री को ZIP फ़ाइल में शामिल नहीं करना चाहते. ZIP फ़ाइल में टॉप-लेवल की डायरेक्ट्री /apiproxy होनी चाहिए.

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

   zip my-new-proxy.zip -r .

   ZIP फ़ाइल में टॉप-लेवल की डायरेक्ट्री /apiproxy होनी चाहिए.

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

   अपलोड करने पर Edge, आपके लिए नए प्रॉक्सी कॉन्फ़िगरेशन के रिविज़न नंबर को बढ़ा देता है इसे.

7. Edge यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करें. (एपीआई प्रॉक्सी में देखें, प्रोजेक्ट > नया बदलाव अपलोड करें.)

   अगर आपको Bundle is invalid. Empty bundle. जैसी कोई गड़बड़ी मिलती है, तो पक्का करें कि आपकी ZIP फ़ाइल की टॉप-लेवल की डायरेक्ट्री /apiproxy है. अगर ऐसा नहीं है, तो अपने बड़ी की गई डायरेक्ट्री के रूट से प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलें.

   अपना नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करने के बाद, Edge रिविज़न की संख्या को बढ़ा देता है और इसे बदलाव की खास जानकारी व्यू में दिखाता है.

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

8. अपने नए बदलाव को डिप्लॉय करें.

ज़्यादा जानकारी के लिए देखें ट्यूटोरियल: YouTube API में यूज़र इंटरफ़ेस (यूआई) और मैनेजमेंट एपीआई का इस्तेमाल करके प्रॉक्सी कैसे डाउनलोड करें Apigee कम्यूनिटी.

एपीआई प्रॉक्सी स्ट्रक्चर

एपीआई प्रॉक्सी में ये कॉन्फ़िगरेशन शामिल होते हैं:

एपीआई प्रॉक्सी डायरेक्ट्री का स्ट्रक्चर और कॉन्टेंट

ऊपर दी गई टेबल के कॉम्पोनेंट, नीचे दी गई कॉन्फ़िगरेशन फ़ाइलों से तय किए गए हैं डायरेक्ट्री स्ट्रक्चर:

कॉन्फ़िगरेशन फ़ाइलें और डायरेक्ट्री एपीआई प्रॉक्सी का स्ट्रक्चर

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

• बुनियादी कॉन्फ़िगरेशन
• ProxyEndpoint
• TargetEndpoint
  • TLS/SSL TargetEndpoint कॉन्फ़िगरेशन
• नीतियां
• फ़्लो
• संसाधन

बुनियादी कॉन्फ़िगरेशन

/apiproxy/weatherapi.xml

एपीआई प्रॉक्सी का बेस कॉन्फ़िगरेशन, जो एपीआई प्रॉक्सी का नाम बताता है. नाम संगठन में यूनीक होना चाहिए.

कॉन्फ़िगरेशन का नमूना:

<APIProxy name="weatherapi">
</APIProxy>

बेस कॉन्फ़िगरेशन एलिमेंट

ProxyEndpoint

नीचे दी गई इमेज में, अनुरोध/रिस्पॉन्स का फ़्लो दिखाया गया है:

/apiproxy/proxies/default.xml

ProxyEndpoint कॉन्फ़िगरेशन, किसी एपीआई के लिए इनबाउंड (क्लाइंट-फ़ेसिंग) इंटरफ़ेस तय करता है प्रॉक्सी. जब आप ProxyEndpoint कॉन्फ़िगर करते हैं, तो आप ऐसा नेटवर्क कॉन्फ़िगरेशन सेट अप कर रहे होते हैं, जो तय करता है कि क्लाइंट ऐप्लिकेशन ('ऐप्लिकेशन') को प्रॉक्सी एपीआई शुरू करने का तरीका बताना चाहिए.

नीचे दिए गए ProxyEndpoint कॉन्फ़िगरेशन का नमूना /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

बेसिक ProxyEndpoint में ज़रूरी कॉन्फ़िगरेशन एलिमेंट ये हैं:

ProxyEndpoint कॉन्फ़िगरेशन Elements

राऊटर के नियम कॉन्फ़िगर करने का तरीका

नाम वाला TargetEndpoint, /apiproxy/targets में मौजूद कॉन्फ़िगरेशन फ़ाइल को दिखाता है, ताकि इस लेख में, ProxyEndpoint की मदद से प्रोसेस होने के बाद राऊटर का नियम किसी अनुरोध को फ़ॉरवर्ड करता है.

उदाहरण के लिए, नीचे दिया गया RouteRule कॉन्फ़िगरेशन को दिखाता है /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

डायरेक्ट यूआरएल को शुरू करना

ProxyEndpoint सीधे तौर पर बैकएंड सेवा भी शुरू कर सकता है. सीधे यूआरएल को शुरू करने की सुविधा, किसी भी प्रॉडक्ट को बायपास कर सकती है /apiproxy/targets में, TargetEndpoints कॉन्फ़िगरेशन को नाम दिया गया है. इस वजह से, TargetEndpoint एक वैकल्पिक एपीआई प्रॉक्सी कॉन्फ़िगरेशन है. हालांकि, सीधे तौर पर बोला जाना का सुझाव नहीं दिया जाता है.

उदाहरण के लिए, नीचे दिया गया RouteRule एक HTTP कॉल http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

शर्तों के साथ रास्ते

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

कंडिशनल रूट रूल, Apigee Edge पर अन्य कंडिशनल स्टेटमेंट की तरह काम करते हैं. शर्तों का रेफ़रंस और वैरिएबल का रेफ़रंस देखें.

उदाहरण के लिए, नीचे दिए गए routeRule का कॉम्बिनेशन पहले, इनबाउंड अनुरोध की पुष्टि करता है एक एचटीटीपी हेडर की वैल्यू होती है. अगर एचटीटीपी हेडर routeTo की वैल्यू TargetEndpoint1 का इस्तेमाल किया जाता है, तो अनुरोध को TargetEndpoint1. अगर ऐसा नहीं होता है, तो इनबाउंड अनुरोध को http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

शून्य रास्ते

जिन स्थितियों में अनुरोध वाला मैसेज को TargetEndpoint पर भेजना ज़रूरी होता है. यह तब उपयोगी होता है, जब ProxyEndpoint सभी ज़रूरी प्रोसेसिंग. उदाहरण के लिए, किसी बाहरी सेवा को कॉल करने के लिए JavaScript का इस्तेमाल करना या लुकअप से एपीआई सेवाओं में डेटा हासिल करना' कुंजी/वैल्यू स्टोर.

उदाहरण के लिए, नीचे दी गई वैल्यू शून्य रूट के बारे में बताती है:

<RouteRule name="GoNowhere"/>

शर्त के हिसाब से शून्य रूट का इस्तेमाल करना मददगार साबित हो सकता है. नीचे दिए गए उदाहरण में, शून्य रूट को एचटीटीपी हेडर request.header.X-DoNothing में null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

याद रखें कि राऊटर के नियम एक-दूसरे से जुड़े हो सकते हैं, इसलिए एक कंडिशनल शून्य रूट आम तौर पर एक होगा रूट रूल के सेट का एक कॉम्पोनेंट है जिसे कंडिशनल रूटिंग को सपोर्ट करने के लिए डिज़ाइन किया गया है.

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

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

TargetEndpoint, प्रॉक्सीएंडपॉइंट का आउटबाउंड जैसा होता है. TargetEndpoint इस तौर पर काम करता है क्लाइंट को किसी बैकएंड सेवा या API से लिंक किया जाता है - यह अनुरोध भेजता है और रिस्पॉन्स देता है.

एपीआई प्रॉक्सी में कोई TargetEndpoints नहीं होना चाहिए. ProxyEndpoints को यूआरएल को कॉल करने के लिए कॉन्फ़िगर किया जा सकता है सकता है. बिना TargetEndpoint वाले एपीआई प्रॉक्सी में आम तौर पर एक ProxyEndpoint होता है, जो सीधे किसी बैकएंड सेवा को कॉल करता है या उसे Java का इस्तेमाल करके या किसी सेवा को कॉल करने के लिए कॉन्फ़िगर किया गया है JavaScript.

TargetEndpoint कॉन्फ़िगरेशन

/targets/default.xml

TargetEndpoint, Apigee Edge से किसी दूसरी सेवा पर आउटबाउंड कनेक्शन को तय करता है या संसाधन.

यहां TargetEndpoint कॉन्फ़िगरेशन का सैंपल दिया गया है:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

TargetEndpoint कॉन्फ़िगरेशन Elements

TargetEndpoint, इनमें से किसी एक तरीके से टारगेट को कॉल कर सकता है:

• HTTP(S) कॉल के लिए HTTPTargetConnection
• लोकल प्रॉक्सी-टू-प्रॉक्सी चेन के लिए LocalTargetConnection
• Edge पर होस्ट किए गए कॉल के लिए ScriptTarget Node.js स्क्रिप्ट

TargetEndpoint में इनमें से सिर्फ़ एक को कॉन्फ़िगर करें.

TLS/SSL TargetEndpoint कॉन्फ़िगरेशन

TargetEndpoints को अक्सर विषम बैकएंड की मदद से एचटीटीपीएस कनेक्शन को मैनेज करने की ज़रूरत पड़ती है किया जा सकता है. इस कारण से, कई TLS/SSL कॉन्फ़िगरेशन सेटिंग समर्थित हैं.

TLS/SSL TargetEndpoint के कॉन्फ़िगरेशन के एलिमेंट

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

आउटबाउंड क्लाइंट की पुष्टि करने की सुविधा चालू होने पर, TargetEndpoint का सैंपल

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

ज़्यादा जानकारी के लिए, TLS कॉन्फ़िगर करना एज से लेकर बैकएंड (क्लाउड और प्राइवेट क्लाउड) तक.

इसका इस्तेमाल किया जा रहा है TLS/एसएसएल वैल्यू को डाइनैमिक तरीके से सेट करने के लिए फ़्लो वैरिएबल

अपने हिसाब से रनटाइम की ज़रूरतों के हिसाब से काम करने के लिए, डाइनैमिक TLS/एसएसएल की जानकारी भी सेट की जा सकती है. उदाहरण के लिए, अगर आपका प्रॉक्सी दो अलग-अलग टारगेट से कनेक्ट होता है (टेस्ट टारगेट और प्रोडक्शन टारगेट) के हिसाब से सेट किया जाता है, तो आप अपने एपीआई प्रॉक्सी को प्रोग्राम के हिसाब से यह पता लगा सकते हैं कि वह कौनसा एनवायरमेंट है कॉल करने और सही कीस्टोर और ट्रस्टस्टोर के लिए डाइनैमिक तौर पर रेफ़रंस सेट करने की सुविधा मिलती है. नीचे दिए गए Apigee कम्यूनिटी के लेख में इस स्थिति के बारे में ज़्यादा जानकारी दी गई है. साथ ही, डिप्लॉय किया जा सकने वाला एपीआई उपलब्ध कराया गया है प्रॉक्सी के उदाहरण: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

नीचे दिए गए उदाहरण में बताया गया है कि <SSLInfo> टैग को TargetEndpoint कॉन्फ़िगरेशन, रनटाइम के दौरान वैल्यू दी जा सकती हैं. उदाहरण के लिए, Java का इस्तेमाल करके कॉलआउट, JavaScript नीति या 'मैसेज असाइन करें' नीति. मैसेज वैरिएबल का इस्तेमाल करें शामिल किए जा सकते हैं, जिन्हें आप सेट करना चाहते हैं.

वैरिएबल की अनुमति सिर्फ़ इन एलिमेंट में दी जाती है.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

इसका इस्तेमाल किया जा रहा है TLS/एसएसएल की वैल्यू डाइनैमिक तरीके से सेट करने के लिए रेफ़रंस

एचटीटीपीएस का इस्तेमाल करने वाले TargetEndpoint को कॉन्फ़िगर करते समय, आपको ऐसा तब करना होगा, जब TLS/एसएसएल सर्टिफ़िकेट की समयसीमा खत्म हो जाती है या सिस्टम कॉन्फ़िगरेशन में बदलाव करने पर, आपको सर्टिफ़िकेट को अपडेट करना होगा. तय सीमा में प्राइवेट क्लाउड इंस्टॉलेशन के लिए Edge, जब टीएलएस/एसएसएल को कॉन्फ़िगर किया जा रहा हो. फ़्लो वैरिएबल का इस्तेमाल करने पर, इस बात की संभावना होती है कि आपको मैसेज प्रोसेसर फिर से शुरू करने पड़ेंगे.

ज़्यादा जानकारी के लिए, TLS अपडेट करें सर्टिफ़िकेट.

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

उदाहरण के लिए, नीचे एक TargetEndpoint दिखाया गया है, जो कीस्टोर के रेफ़रंस का इस्तेमाल करता है:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

इस नाम वाली रेफ़रंस फ़ाइल बनाने के लिए, नीचे दिए गए POST API कॉल का इस्तेमाल करें keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

रेफ़रंस, कीस्टोर का नाम और उसके टाइप के बारे में बताता है.

रेफ़रंस फ़ाइल देखने के लिए, इस जीईटी एपीआई कॉल का इस्तेमाल करें:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

किसी दूसरे कीस्टोर पर ले जाने के लिए, बाद में रेफ़रंस बदलने के लिए, पक्का करें कि उपनाम में समान नाम, निम्न PUT कॉल का उपयोग करें:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint वह भी कसरत के दौरान,

TargetEndpoints, तीन लोड का इस्तेमाल करके नाम वाले कई TargetServers में लोड बैलेंस करने की सुविधा देता है बैलेंस करने वाले एल्गोरिदम.

ज़्यादा जानकारी के लिए, बैकएंड में लोड बैलेंसिंग की जानकारी देखें सर्वर पर सेव कर सकें.

नीतियां

एपीआई प्रॉक्सी की /policies डायरेक्ट्री में, सभी उपलब्ध नीतियां शामिल होती हैं API प्रॉक्सी में फ़्लो से अटैच हो जाता है.

नीति के कॉन्फ़िगरेशन एलिमेंट

नीति अटैचमेंट

नीचे दी गई इमेज में, एपीआई प्रॉक्सी फ़्लो को लागू करने का क्रम दिखाया गया है:

जैसा कि ऊपर दिखाया गया है:

नीतियों को फ़्लो के प्रोसेस के चरणों के तौर पर अटैच किया गया है. नीति के नाम का इस्तेमाल इन कामों के लिए किया जाता है संसाधन चरण के रूप में लागू की जाने वाली नीति का संदर्भ दें. नीति अटैचमेंट का फ़ॉर्मैट यह है निम्न:

<Step><Name>MyPolicy</Name></Step>

नीतियां उसी क्रम में लागू की जाती हैं जिस क्रम में वे किसी फ़्लो से जुड़ी होती हैं. उदाहरण के लिए:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

नीति अटैचमेंट का कॉन्फ़िगरेशन Elements

फ़्लो

ProxyEndpoint और TargetEndpoint, अनुरोध और जवाब वाले मैसेज के लिए एक पाइपलाइन तय करते हैं प्रोसेस चल रही है. प्रोसेसिंग पाइपलाइन में, अनुरोध और रिस्पॉन्स का फ़्लो शामिल होता है. हर अनुरोध फ़्लो और रिस्पॉन्स फ़्लो को PreFlow, एक या एक से ज़्यादा वैकल्पिक 'कंडिशनल' में बांटा गया है या 'नाम' और PostFlow, दोनों को शामिल करते हैं.

• PreFlow: हमेशा काम करता है. यह किसी भी कंडिशनल फ़्लो से पहले लागू होता है.
• PostFlow: हमेशा काम करता है. यह किसी भी कंडिशनल फ़्लो के बाद लागू होता है.

इसके अलावा, आप ProxyEndpoint में PostClientFlow जोड़ सकते हैं, जो अनुरोध करने वाले क्लाइंट के ऐप्लिकेशन को रिस्पॉन्स भेजा जाता है. सिर्फ़ MessageLogging नीति और Google स्टैकड्राइवर लॉगिंग एक्सटेंशन अटैच किया जा सकता है इस फ़्लो में शामिल हो जाएंगे. PostClientFlow, एपीआई प्रॉक्सी इंतज़ार के समय को कम करता है और यह एक ऐसी लॉगिंग है जिसकी गणना तब तक नहीं की जाती, जब तक कि क्लाइंट को रिस्पॉन्स लौटा नहीं दिया जाता, जैसे client.sent.start.timestamp और client.sent.end.timestamp.फ़्लो का इस्तेमाल किया जाता है मुख्य तौर पर, किसी रिस्पॉन्स के शुरू और खत्म होने के टाइमस्टैंप के बीच के समय को मापने के लिए दिखाई देगा.

कोई तरीका सिखाने वाला झटपट वीडियो देखें

यहां PostClientFlow का एक उदाहरण दिया गया है, जिसमें मैसेज लॉग करने की नीति अटैच की गई है.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

एपीआई प्रॉक्सी प्रोसेसिंग पाइपलाइन नीचे दिए गए क्रम में फ़्लो लागू करती है:

पाइपलाइन का अनुरोध करें:

1. प्रॉक्सी अनुरोध प्रीफ़्लो
2. प्रॉक्सी अनुरोध की शर्त के हिसाब से फ़्लो (ज़रूरी नहीं)
3. प्रॉक्सी अनुरोध पोस्टफ़्लो
4. टारगेट रिक्वेस्ट प्रीफ़्लो
5. लक्ष्य अनुरोध के शर्त वाले फ़्लो (ज़रूरी नहीं)
6. टारगेट रिक्वेस्ट पोस्टफ़्लो

रिस्पॉन्स पाइपलाइन:

1. टारगेट रिस्पॉन्स प्रीफ़्लो
2. टारगेट जवाब के कंडिशनल फ़्लो (ज़रूरी नहीं)
3. टारगेट रिस्पॉन्स पोस्टफ़्लो
4. प्रॉक्सी रिस्पॉन्स प्रीफ़्लो
5. प्रॉक्सी रिस्पॉन्स कंडिशनल फ़्लो (ज़रूरी नहीं)
6. प्रॉक्सी रिस्पॉन्स पोस्टफ़्लो
7. PostClientFlow रिस्पॉन्स (ज़रूरी नहीं)

सिर्फ़ नीति वाले अटैचमेंट वाले फ़्लो को ही ProxyEndpoint में कॉन्फ़िगर करना होगा या TargetEndpoint कॉन्फ़िगरेशन. PreFlow और PostFlow को सिर्फ़ ProxyEndpoint में बताना ज़रूरी है या जब PreFlow या PostFlow के दौरान किसी नीति को लागू करने की ज़रूरत होती है, तब TargetEndpoint कॉन्फ़िगरेशन प्रोसेस चल रही है.

कंडिशनल फ़्लो के उलट, PreFlow और PostFlow एलिमेंट का क्रम ज़रूरी--एपीआई प्रॉक्सी हर एक को पाइपलाइन में सही पॉइंट पर एक्ज़ीक्यूट करेगा, भले ही, एंडपॉइंट कॉन्फ़िगरेशन में वे कहीं भी दिखें.

कंडिशनल फ़्लो

ProxyEndpoints और TargetEndpoints की मदद से, बिना किसी शर्त वाले फ़्लो की संख्या अनलिमिटेड की जा सकती है ( जिसे 'नेम्ड फ़्लो' कहा जाता है).

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

कंडिशनल फ़्लो तय करने पर, आपको एपीआई प्रॉक्सी में प्रोसेसिंग के चरण लागू करने की सुविधा मिलती है इस पर आधारित:

• अनुरोध URI
• एचटीटीपी क्रिया (GET/PUT/POST/DELETE)
• क्वेरी पैरामीटर, हेडर, और फ़ॉर्म पैरामीटर का मान
• कई अन्य तरह की स्थितियां

उदाहरण के लिए, नीचे दिया गया कंडिशनल फ़्लो बताता है कि यह सिर्फ़ तब लागू होता है, जब अनुरोध किए गए संसाधन का पाथ /accesstoken है. ऐसा कोई भी इनबाउंड अनुरोध पाथ /accesstoken की वजह से, सभी नीतियों के साथ यह फ़्लो भी चलता है जो फ़्लो से जुड़े हों. अगर अनुरोध के पाथ में सफ़िक्स शामिल नहीं है /accesstoken है, तो फ़्लो लागू नहीं होता है (हालांकि, एक और कंडिशनल फ़्लो नहीं है कर सकते हैं).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

फ़्लो कॉन्फ़िगरेशन एलिमेंट

चरणों की प्रोसेसिंग

कंडिशनल फ़्लो को क्रम में लगाने के लिए, Apigee Edge का इस्तेमाल किया जाता है. कंडिशनल फ़्लो ऊपर से नीचे तक लागू करता है. पहला कंडिशनल फ़्लो, जिसकी शर्त का आकलन होता है true चलाया जाता है और सिर्फ़ एक शर्त वाला फ़्लो लागू होता है.

उदाहरण के लिए, नीचे दिए गए फ़्लो कॉन्फ़िगरेशन में, ऐसा कोई भी इनबाउंड अनुरोध जिसमें शामिल न हो पाथ सफ़िक्स /first या /second की वजह से ThirdFlow लागू करने के लिए, Return404 नाम की नीति को लागू करें.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

संसाधन

"संसाधन" (एपीआई प्रॉक्सी में इस्तेमाल करने के लिए संसाधन फ़ाइलें) स्क्रिप्ट, कोड, और XSL ट्रांसफ़ॉर्मेशन हैं जिसे नीतियों का इस्तेमाल करके, Flows पर अटैच किया जा सकता है. ये "स्क्रिप्ट" में दिखाई देते हैं सेक्शन में मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) में प्रॉक्सी एडिटर.

इस्तेमाल की जा सकने वाली फ़ाइलों के लिए संसाधन फ़ाइलें देखें संसाधन प्रकार.

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

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