एपीआई प्रॉक्सी डिज़ाइन और डेवलपमेंट के लिए सबसे सही तरीके

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

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

यहां दिए गए दिशा-निर्देशों के अलावा, आपको Apigee Edge के एंटीपैटर्न कम्यूनिटी पोस्ट से मदद मिल सकती है.

डेवलपमेंट स्टैंडर्ड

टिप्पणियां और दस्तावेज़

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

फ़्रेमवर्क शैली की कोडिंग

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

  • जहां संभव हो, DRY ("खुद को बार-बार न दोहराएं") को चालू करने के लिए, नीति कॉन्फ़िगरेशन और स्क्रिप्ट में कुछ खास और फिर से इस्तेमाल किए जा सकने वाले फ़ंक्शन लागू करने चाहिए. उदाहरण के लिए, अनुरोध वाले मैसेज से क्वेरी पैरामीटर निकालने के लिए बनाई गई खास नीति को ExtractVariables.ExtractRequestParameters कहा जा सकता है. सीओआरएस हेडर इंजेक्ट करने के लिए बनी खास नीति को AssignMessage.SetCORSHeaders कहा जा सकता है. इसके बाद, इन नीतियों को आपके सोर्स कंट्रोल सिस्टम में सेव किया जा सकता है. साथ ही, हर उस एपीआई प्रॉक्सी में जोड़ा जा सकता है जिसे पैरामीटर एक्सट्रैक्ट करने या सीओआरएस हेडर सेट करने की ज़रूरत होती है. इसके लिए, आपको ग़ैर-ज़रूरी कॉन्फ़िगरेशन बनाने की ज़रूरत नहीं होती और वे मैनेज नहीं किए जा सकते.
  • इस्तेमाल न की गई नीतियों और संसाधनों (JavaScript, Java, XSLT वगैरह) को एपीआई प्रॉक्सी से हटाएं. खास तौर पर, ऐसे बड़े संसाधन जिनमें इंपोर्ट करने की प्रोसेस को धीमा करने और प्रोसेस को डिप्लॉय करने की प्रोसेस को कम किया जा सकता है.

नामकरण सम्मेलन

  • नीति name एट्रिब्यूट और एक्सएमएल नीति फ़ाइल का नाम एक जैसे होने चाहिए.
  • स्क्रिप्ट और सेवा कॉलआउट की नीति name एट्रिब्यूट और रिसॉर्स फ़ाइल का नाम एक जैसा होना चाहिए.
  • DisplayName को किसी ऐसे व्यक्ति को नीति के काम करने के तरीके के बारे में सटीक जानकारी देनी चाहिए जिसने पहले कभी उस एपीआई प्रॉक्सी के साथ काम नहीं किया है.
  • नीतियों को उनके काम के हिसाब से नाम देना. Apigee का सुझाव है कि आप अपनी नीतियों के लिए एक जैसे नाम रखने का तरीका बनाएं. उदाहरण के लिए, छोटे प्रीफ़िक्स का इस्तेमाल करें. इसके बाद, ब्यौरे वाले शब्दों को डैश से अलग करके क्रम में लगाएं. उदाहरण के लिए, AssignmentsMessage की नीतियों के लिए AM-xxx. apigeelint टूल भी देखें.
  • रिसॉर्स फ़ाइलों के लिए सही एक्सटेंशन, JavaScript के लिए .js, Python के लिए .py, और Java JAR फ़ाइलों के लिए .jar इस्तेमाल करें.
  • वैरिएबल के नाम एक जैसे होने चाहिए. अगर आप ऊंट या अंडरस्कोर जैसी कोई स्टाइल चुनते हैं, तो इसे एपीआई प्रॉक्सी में इस्तेमाल करें.
  • जहां भी हो सके, वैरिएबल प्रीफ़िक्स का इस्तेमाल करें, ताकि वैरिएबल को उनके मकसद के आधार पर व्यवस्थित किया जा सके. जैसे, Consumer.username और Consumer.password.

एपीआई प्रॉक्सी डेवलपमेंट

शुरुआती डिज़ाइन के लिए ध्यान देने वाली बातें

  • RESTful API के डिज़ाइन के बारे में दिशा-निर्देश पाने के लिए, ई-बुक Web API डिज़ाइन: The गुम लिंक डाउनलोड करें.
  • जहां भी मुमकिन हो, एपीआई प्रॉक्सी बनाने के लिए Apigee Edge की नीतियों और फ़ंक्शन का फ़ायदा लें. JavaScript, Java या Python संसाधनों में सभी प्रॉक्सी लॉजिक को कोडिंग करने से बचें.
  • फ़्लो को व्यवस्थित तरीके से बनाएं. एक ही शर्त वाले कई फ़्लो, एक ही PreFlow और Postflow के लिए कई कंडिशनल अटैचमेंट के बजाय, एक से ज़्यादा फ़्लो को प्राथमिकता देते हैं.
  • 'failsafe' के तौर पर, / के प्रॉक्सीEndpoint BasePath के साथ डिफ़ॉल्ट एपीआई प्रॉक्सी बनाएं. इसका इस्तेमाल, बेस एपीआई अनुरोधों को डेवलपर साइट पर रीडायरेक्ट करने, पसंद के मुताबिक जवाब देने या डिफ़ॉल्ट messaging.adaptors.http.flow.ApplicationNotFound पर वापस जाने के बजाय ज़्यादा काम की कोई दूसरी कार्रवाई करने के लिए किया जा सकता है.
  • टारगेट सर्वर के संसाधनों का इस्तेमाल करके, कंक्रीट यूआरएल से TargetEndpoint कॉन्फ़िगरेशन को अलग करें. इससे सभी प्लैटफ़ॉर्म पर प्रमोशन किया जा सकता है.
    सभी बैकएंड सर्वर पर लोड बैलेंसिंग देखें.
  • अगर आपके पास कई Routeरूल हैं, तो एक को 'डिफ़ॉल्ट' के तौर पर बनाएं. इसका मतलब बिना किसी शर्त के रूट रूल के तौर पर सेट करना है. पक्का करें कि कंडिशनल रूट की सूची में, डिफ़ॉल्ट रूटिंग नियम, सबसे आखिर में तय किया गया है. प्रॉक्सीEndpoint में Routeरूल का आकलन किया जाता है.
    एपीआई प्रॉक्सी कॉन्फ़िगरेशन से जुड़ी जानकारी देखें.
  • API प्रॉक्सी बंडल का आकार: API प्रॉक्सी बंडल का आकार 15MB से बड़ा नहीं हो सकता. Private Cloud के लिए Apigee Edge में, साइज़ की सीमा बदली जा सकती है. इसके लिए, इन जगहों पर दी गई thrift_framed_transport_size_in_mb प्रॉपर्टी में बदलाव करें: cassandra.yaml (Cassandra में) और conf/apigee/management-server/repository.properties.
  • एपीआई वर्शनिंग: एपीआई वर्शन बनाने के बारे में Apigee के विचार और सुझाव देखने के लिए, वेब एपीआई डिज़ाइन: लिंक मौजूद नहीं है ई-बुक में वर्शन देखें.

सीओआरएस की सुविधा चालू करना

अपने एपीआई पब्लिश करने से पहले, आपको अपने एपीआई प्रॉक्सी पर सीओआरएस चालू करना होगा, ताकि क्लाइंट-साइड क्रॉस-ऑरिजिन अनुरोधों के साथ काम किया जा सके.

सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) एक स्टैंडर्ड तरीका है. इसकी मदद से, किसी वेब पेज पर बनाए गए JavaScript XMLHttpRequest (XHR) कॉल को, नॉन-ऑरिजिन डोमेन के रिसॉर्स के साथ इंटरैक्ट करने की अनुमति मिलती है. सीओआरएस, आम तौर पर एक ही ऑरिजिन से जुड़ी नीति के लिए लागू किया जाने वाला समाधान है. इसे सभी ब्राउज़र लागू करते हैं. उदाहरण के लिए, अगर ब्राउज़र में JavaScript कोड का इस्तेमाल करके, Twitter API को XHR कॉल किया जाता है, तो कॉल फ़ेल हो जाएगा. इसकी वजह यह है कि आपके ब्राउज़र पर पेज को दिखाने वाला डोमेन और Twitter API को उपलब्ध कराने वाला डोमेन, दोनों एक जैसे नहीं हैं. अगर सर्वर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग की सुविधा देना चाहते हैं, तो सीओआरएस से सर्वर को "ऑप्ट-इन" करने की अनुमति देकर इस समस्या का समाधान मिलता है.

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

मैसेज पेलोड का साइज़

Edge में मेमोरी की समस्याओं से बचने के लिए, मैसेज पेलोड का साइज़ 10 एमबी तक सीमित किया गया है. इन साइज़ से ज़्यादा होने पर, protocol.http.TooBigBody गड़बड़ी होगी.

इस समस्या के बारे में Apigee की इस कम्यूनिटी पोस्ट में भी बताया गया है.

Edge में बड़े साइज़ के मैसेज को हैंडल करने के लिए, यहां सुझाई गई रणनीतियां दी गई हैं:

  • स्ट्रीम के अनुरोध और जवाब. ध्यान दें कि स्ट्रीम करने के बाद, नीतियों के पास मैसेज के कॉन्टेंट का ऐक्सेस नहीं रहता. स्ट्रीमिंग के अनुरोध और जवाब देखें.
  • Edge के लिए प्राइवेट क्लाउड वर्शन 4.15.07 और इससे पहले के वर्शन में, HTTPResponse.body.buffer.limit पैरामीटर की सीमा बढ़ाने के लिए मैसेज प्रोसेसर http.properties फ़ाइल में बदलाव करें. प्रोडक्शन में इस बदलाव को लागू करने से पहले, उसकी जांच ज़रूर कर लें.
  • Edge for Private Cloud वर्शन 4.16.01 और इसके बाद के वर्शन में, पेलोड के साथ किए गए अनुरोधों में कॉन्टेंट की लंबाई का हेडर शामिल होना चाहिए. इसके अलावा, "Transfer-Encrypt: Chnked" हेडर को स्ट्रीम करने के मामले में, यह ज़रूरी है. खाली पेलोड वाले एपीआई प्रॉक्सी के POST के लिए, आपको 0 की कॉन्टेंट-अवधि पास करनी होगी.
  • Edge for Private Cloud वर्शन 4.16.01 और इसके बाद के वर्शन में, इन सीमाओं को बदलने के लिए, /opt/apigee/router.properties या message-processor.properties में सेट करें. ज़्यादा जानकारी के लिए, रूटर या मैसेज प्रोसेसर पर मैसेज के साइज़ की सीमा सेट करना देखें.

    दोनों प्रॉपर्टी की डिफ़ॉल्ट वैल्यू 10 एमबी के हिसाब से "10 मीटर" होती है:
    • conf_http_HTTPRequest.body.buffer.limit
    • conf_http_HTTPResponse.body.buffer.limit

गड़बड़ी ठीक करना

  • सभी तरह की गड़बड़ियों को ठीक करने के लिए, गड़बड़ी ठीक करने के नियम आज़माएं. (riseFault की नीतियों का इस्तेमाल मैसेज के फ़्लो को रोकने और उसे प्रोसेस करने के दौरान गड़बड़ी को भेजने के लिए किया जाता है.)
  • गड़बड़ी का जवाब तैयार करने के लिए, FaultTerms फ़्लो में, 'RightMessage की नीतियों' का इस्तेमाल करें, न कि riseFault की नीतियों का. गड़बड़ी के टाइप के आधार पर, Assignments मैसेज की नीतियों को कुछ शर्तों के साथ लागू करें.
  • इसमें हमेशा एक डिफ़ॉल्ट 'कैच-ऑल' गड़बड़ी हैंडलर शामिल होता है, ताकि सिस्टम से जनरेट की गई गड़बड़ियों को ग्राहक के तय किए गए गड़बड़ी रिस्पॉन्स फ़ॉर्मैट के साथ मैप किया जा सके.
  • अगर हो सके, तो हमेशा गड़बड़ी के जवाब अपनी कंपनी या प्रोजेक्ट में मौजूद स्टैंडर्ड फ़ॉर्मैट से मेल खाएं.
  • गड़बड़ी के ऐसे मैसेज इस्तेमाल करें जिन्हें लोग आसानी से पढ़ सकें. ये मैसेज, गड़बड़ी को ठीक करने के तरीकों के बारे में बताते हैं.

गड़बड़ियां ठीक करना देखें.

इंडस्ट्री के सबसे सही तरीकों के बारे में जानने के लिए, RESTful गड़बड़ी के जवाब का डिज़ाइन देखें.

स्थायी

कुंजी/वैल्यू मैप

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

की वैल्यू को मैप करने पर होने वाली कार्रवाइयों की नीति देखें.

रिस्पॉन्स कैश मेमोरी में सेव करना

  • अगर रिस्पॉन्स पूरा नहीं होता या अनुरोध जीईटी नहीं है, तो रिस्पॉन्स कैश मेमोरी में अपने-आप जानकारी न भरें. कॉन्टेंट बनाने, अपडेट करने, और मिटाने की सुविधा को कैश मेमोरी में सेव नहीं किया जाना चाहिए. <SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation>
  • कैश मेमोरी में, एक ही तरह के कॉन्टेंट का इस्तेमाल करें, जैसे कि एक्सएमएल या JSON. रिस्पॉन्स कैश एंट्री वापस पाने के बाद, उसे JSONtoXML या XMLToJSON के साथ ज़रूरी कॉन्टेंट टाइप में बदलें. इससे डबल, तिहरा या ज़्यादा डेटा सेव नहीं किया जाएगा.
  • पक्का करें कि कैश मेमोरी कुंजी, कैश मेमोरी की ज़रूरत के हिसाब से हो. कई मामलों में, request.querystring को यूनीक आइडेंटिफ़ायर के तौर पर इस्तेमाल किया जा सकता है.
  • जब तक साफ़ तौर पर ज़रूरी न हो, तब तक कैश कुंजी में एपीआई कुंजी (client_id) शामिल न करें. आम तौर पर, सिर्फ़ किसी कुंजी से सुरक्षित किए गए एपीआई, किसी अनुरोध के लिए सभी क्लाइंट को वही डेटा दिखाएंगे. एपीआई पासकोड के आधार पर, कई एंट्री के लिए एक ही वैल्यू सेव नहीं किया जा सकता.
  • गड़बड़ी वाले कॉन्टेंट से बचने के लिए, कैश मेमोरी की समयसीमा खत्म होने का सही इंटरवल सेट करें.
  • जब भी हो सके, रिस्पॉन्स कैश मेमोरी की नीति को लागू करने की कोशिश करें. यह नीति जितना हो सके उतनी देर से प्रॉक्सीEndpoint रिस्पॉन्स PostFlow पर, कैश को एक्ज़ीक्यूट करती है. दूसरे शब्दों में, इसे अनुवाद और मीडिएशन के चरणों के बाद एक्ज़ीक्यूट करें. इसमें JavaScript पर आधारित मीडिएशन और JSON और एक्सएमएल के बीच कन्वर्ज़न भी शामिल है. मीडिएशन वाले डेटा को कैश मेमोरी में सेव करने से, हर बार कैश मेमोरी में सेव किया गया डेटा वापस पाने पर, मीडिएशन चरण को लागू करने की परफ़ॉर्मेंस लागत से बचा जा सकता है.

    ध्यान दें कि अगर मीडिएशन की वजह से, अनुरोध के अनुरोध से अलग रिस्पॉन्स मिलता है, तो हो सकता है कि आप बिना मीडिएशन वाले डेटा को कैश मेमोरी में सेव करना चाहें.

  • कैश एंट्री को देखने के लिए रिस्पॉन्स कैश मेमोरी की नीति, प्रॉक्सीEndpoint अनुरोध PreFlow में होनी चाहिए. कैश एंट्री पर वापस जाने से पहले, कैश कुंजी जनरेट करने के अलावा, बहुत ज़्यादा लॉजिक को लागू करने से बचें. अगर ऐसा नहीं किया जाता है, तो कैश मेमोरी में सेव करने के फ़ायदे कम हो जाते हैं.
  • आम तौर पर, आपको रिस्पॉन्स कैश लुकअप को हमेशा क्लाइंट के अनुरोध के आस-पास रखना चाहिए. इसके उलट, आपको रिस्पॉन्स कैश मेमोरी में सेव किए गए डेटा को क्लाइंट के रिस्पॉन्स के ज़्यादा से ज़्यादा पास रखना चाहिए.
  • प्रॉक्सी में अलग-अलग रिस्पॉन्स कैश नीतियों का इस्तेमाल करते समय, इन दिशा-निर्देशों का पालन करें. इससे यह पक्का किया जा सकेगा कि हर एक का अलग-अलग व्यवहार हो:
    • म्यूचुअली एक्सक्लूसिव शर्तों के आधार पर हर नीति का पालन करें. इससे यह पक्का करने में मदद मिलेगी कि रिस्पॉन्स कैश मेमोरी की कई नीतियों में से सिर्फ़ एक नीति लागू हो.
    • कैश मेमोरी से जुड़ी हर नीति के लिए, कैश मेमोरी के अलग-अलग रिसॉर्स तय करें. कैश रिसॉर्स को नीति के <cacheResource> एलिमेंट में तय किया जा सकता है.

रिस्पॉन्स कैश मेमोरी से जुड़ी नीति देखें.

नीति और कस्टम कोड

नीति या कस्टम कोड?

  • जहां तक हो सके, पहले और सबसे अहम तरीके से पहले से मौजूद नीतियों का इस्तेमाल करें. Apigee की नीतियों को सख्त, ऑप्टिमाइज़, और इस्तेमाल किया जा सकता है. उदाहरण के लिए, पेलोड बनाने, पेलोड (XPath, JSONPath) वगैरह से जानकारी निकालने के लिए, JavaScript (जब मुमकिन हो) के बजाय स्टैंडर्ड AssignmentsMessage और ExtractVariables नीतियों का इस्तेमाल करें.
  • Python और Java के बजाय, JavaScript को प्राथमिकता दी जाती है. हालांकि, अगर JavaScript के लिए सबसे अहम भूमिका निभाना है, तो JavaScript की जगह Java का इस्तेमाल करना चाहिए.

JavaScript

  • अगर JavaScript को Apigee नीतियों से ज़्यादा आसान लगता है, तो इसका इस्तेमाल करें. उदाहरण के लिए, कई अलग-अलग यूआरआई के कॉम्बिनेशन के लिए target.url सेट करते समय.
  • कॉम्प्लेक्स पेलोड पार्स करना, जैसे कि JSON ऑब्जेक्ट को दोहराना और Base64 कोड को कोड में बदलने का तरीका/डिकोडिंग.
  • JavaScript नीति की समयसीमा तय है. इसलिए, इनफ़ाइनाइट लूप को ब्लॉक किया जाता है.
  • हमेशा JavaScript के चरण इस्तेमाल करें और फ़ाइलों को jsc रिसॉर्स फ़ोल्डर में रखें. JavaScript नीति प्रकार, डिप्लॉयमेंट के समय कोड को पहले से कंपाइल करता है.

JavaScript की मदद से प्रोग्रामिंग एपीआई प्रॉक्सी देखें.

Java

  • अगर परफ़ॉर्मेंस सबसे ज़्यादा प्राथमिकता है या JavaScript में लॉजिक को लागू नहीं किया जा सकता, तो Java का इस्तेमाल करें.
  • सोर्स कोड ट्रैकिंग में Java सोर्स फ़ाइलें शामिल करें.

एपीआई प्रॉक्सी में Java का इस्तेमाल करने के बारे में जानकारी पाने के लिए, Java कॉलआउट की मदद से रिस्पॉन्स को अपरकेस में बदलें और Java कॉलआउट नीति देखें.

Python

  • जब तक कि बहुत ज़रूरी न हो, Python का इस्तेमाल न करें. Python स्क्रिप्ट, आसान एक्ज़ीक्यूशन के लिए परफ़ॉर्मेंस से जुड़ी बॉटलनेक जोड़ सकती हैं, क्योंकि इसे रनटाइम पर इंटरप्रेट किया जाता है.

स्क्रिप्ट कॉलआउट (Java, JavaScript, Python)

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

JavaScript

  • एपीआई प्लैटफ़ॉर्म पर मौजूद JavaScript, E4X की मदद से एक्सएमएल का इस्तेमाल करता है.

JavaScript ऑब्जेक्ट मॉडल देखें.

Java

  • मैसेज पेलोड ऐक्सेस करते समय, context.getMessage() बनाम context.getResponseMessage या context.getRequestMessage इस्तेमाल करके देखें. इससे यह पक्का होता है कि कोड, अनुरोध और रिस्पॉन्स, दोनों फ़्लो में पेलोड वापस ला सकता है.
  • लाइब्रेरी को Apigee Edge के संगठन या एनवायरमेंट में इंपोर्ट करें. उन्हें JAR फ़ाइल में शामिल न करें. इससे बंडल का साइज़ कम हो जाता है और दूसरी JAR फ़ाइलें उसी लाइब्रेरी रिपॉज़िटरी को ऐक्सेस कर पाएंगी.
  • JAR फ़ाइलों को एपीआई प्रॉक्सी रिसॉर्स फ़ोल्डर में शामिल करने के बजाय, Apigee रिसॉर्स एपीआई का इस्तेमाल करके इंपोर्ट करें. इससे डिप्लॉयमेंट में लगने वाला समय कम हो जाएगा. साथ ही, एक जैसी JAR फ़ाइलों को एक से ज़्यादा एपीआई प्रॉक्सी का इस्तेमाल करने की अनुमति मिल जाएगी. दूसरा फ़ायदा, क्लास लोडर आइसोलेशन है.
  • रिसॉर्स हैंडलिंग के लिए Java का इस्तेमाल न करें. जैसे, थ्रेड पूल बनाना और उन्हें मैनेज करना.

Java कॉलआउट की मदद से रिस्पॉन्स को अपरकेस में बदलें देखें.

Python

  • Apigee गड़बड़ी के जवाबों में इस्तेमाल करने के लिए, सही अपवादों को सेट करें और उन्हें सही तरीके से पकड़ें

Python स्क्रिप्ट की नीति देखें.

ServiceCallouts

  • प्रॉक्सी चेन का इस्तेमाल करने के कई मान्य उदाहरण हैं, जब किसी एपीआई प्रॉक्सी को दूसरी एपीआई प्रॉक्सी को कॉल करने के लिए, सेवा कॉलआउट का इस्तेमाल किया जाता है. अगर प्रॉक्सी चेन का इस्तेमाल किया जाता है, तो "इनफ़ाइनाइट लूप" बार-बार होने वाले कॉलआउट को उसी एपीआई प्रॉक्सी में न डालें.

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

  • assignMessage नीति का इस्तेमाल करके, सेवा कॉलआउट के अनुरोध का मैसेज बनाएं और अनुरोध ऑब्जेक्ट को मैसेज वैरिएबल में भरें. (इसमें अनुरोध पेलोड, पाथ, और तरीका सेट करना शामिल है.)
  • नीति में कॉन्फ़िगर किए गए यूआरएल के लिए, प्रोटोकॉल से जुड़ी जानकारी देना ज़रूरी होता है. इसका मतलब है कि यूआरएल के प्रोटोकॉल वाले हिस्से, https:// को वैरिएबल से तय नहीं किया जा सकता. साथ ही, आपको यूआरएल के डोमेन वाले हिस्से और यूआरएल के बाकी हिस्से के लिए, अलग-अलग वैरिएबल इस्तेमाल करने होंगे. उदाहरण के लिए: https://{domain}/{path}
  • सेवा कॉलआउट के लिए रिस्पॉन्स ऑब्जेक्ट को एक अलग मैसेज वैरिएबल में स्टोर करें. इसके बाद, मैसेज वैरिएबल को पार्स किया जा सकता है और ओरिजनल मैसेज पेलोड को दूसरी नीतियों में इस्तेमाल करने के लिए वैसा ही रखा जा सकता है.

सेवा कॉलआउट की नीति देखें.

इकाइयां ऐक्सेस करना

AccessEntity की नीति

  • बेहतर परफ़ॉर्मेंस के लिए, ऐप्लिकेशन के नाम के बजाय uuid तक ऐप्लिकेशन खोजें.

ऐक्सेस इकाई की नीति देखें.

लॉग इन हो रहा है

  • एक ही बंडल में और सभी बंडल में एक ही तरह की syslog नीति का इस्तेमाल करें. इससे, डेटा को लॉग करने का एक जैसा फ़ॉर्मैट बना रहेगा.

MessageLogging नीति देखें.

निगरानी

क्लाउड का इस्तेमाल करने वाले ग्राहकों को Apigee Edge (रूटीन, मैसेज प्रोसेसर वगैरह) के अलग-अलग कॉम्पोनेंट की जांच करने की ज़रूरत नहीं है. Apigee की ग्लोबल ऑपरेशंस टीम, सभी कॉम्पोनेंट पर नज़र रख रही है. साथ ही, ग्राहक के अनुरोध के आधार पर, एपीआई की परफ़ॉर्मेंस की जांच भी की जा रही है.

Apigee आंकड़े

गड़बड़ी का प्रतिशत मेज़र किया जाता है, इसलिए Analytics गैर-ज़रूरी एपीआई की निगरानी करने की सुविधा दे सकता है.

Analytics डैशबोर्ड देखें.

ट्रेस

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

ट्रेस टूल का इस्तेमाल करना देखें.

सुरक्षा

  • अपने टेस्ट एनवायरमेंट के ऐक्सेस को सीमित करने के लिए, आईपी पते पर पाबंदी लगाने की नीतियों का इस्तेमाल करें. अपनी डेवलपमेंट मशीन या एनवायरमेंट के आईपी पतों को ऐक्सेस करने की अनुमति दें. साथ ही, बाकी सभी को अनुमति न दें. ऐक्सेस कंट्रोल की नीति.
  • प्रोडक्शन के लिए डिप्लॉय किए गए एपीआई प्रॉक्सी पर, हमेशा कॉन्टेंट की सुरक्षा से जुड़ी नीतियां (JSON और एक्सएमएल) लागू करें. JSON][Protection की नीति.
  • सुरक्षा के और सबसे सही तरीकों के बारे में जानने के लिए, ये विषय देखें: