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

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

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

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

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

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

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

फ़्रेमवर्क-स्टाइल कोडिंग

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

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

नेमिंग कन्वेंशन

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

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

डिज़ाइन से जुड़ी शुरुआती बातें

  • RESTful API के डिज़ाइन के बारे में दिशा-निर्देश पाने के लिए, वेब एपीआई डिज़ाइन: मिसिंग लिंक ई-बुक डाउनलोड करें.
  • एपीआई प्रॉक्सी बनाने के लिए, जहां भी हो सके वहां Apigee Edge की नीतियों और फ़ंक्शन का फ़ायदा लें. JavaScript, Java या Python संसाधनों में सभी प्रॉक्सी लॉजिक कोड करने से बचें.
  • व्यवस्थित तरीके से फ़्लो बनाएं. एक ही शर्त वाले कई फ़्लो, एक ही प्रीफ़्लो और पोस्टफ़्लो में कई शर्तों वाले अटैचमेंट के मुकाबले बेहतर होते हैं.
  • 'फ़ेल-सेफ़' के तौर पर, / के ProxyEndpoint BasePath के साथ डिफ़ॉल्ट एपीआई प्रॉक्सी बनाएं. इसका इस्तेमाल, डेवलपर साइट पर बेस एपीआई अनुरोधों को रीडायरेक्ट करने के लिए किया जा सकता है, ताकि कोई कस्टम रिस्पॉन्स दिया जा सके या डिफ़ॉल्ट messaging.adaptors.http.flow.ApplicationNotFound दिखाने के बजाय कोई और काम की कार्रवाई की जा सके.
  • TargetEndpoint कॉन्फ़िगरेशन को खास यूआरएल से अलग करने के लिए, TargetServer संसाधनों का इस्तेमाल करें. इससे सभी एनवायरमेंट में प्रमोशन की सुविधा मिलती है.
    बैकएंड सर्वर पर लोड को संतुलित करने के बारे में जानें.
  • अगर आपके पास एक से ज़्यादा RouteRules हैं, तो एक को 'डिफ़ॉल्ट' के तौर पर बनाएं. इसका मतलब है कि बिना किसी शर्त के RouteRule बनाएं. पक्का करें कि डिफ़ॉल्ट RouteRule, शर्त के मुताबिक तय किए गए रास्तों की सूची में सबसे आखिर में तय किया गया हो. ProxyEndpoint में, RouteRules का आकलन ऊपर से नीचे की ओर किया जाता है.
    एपीआई प्रॉक्सी कॉन्फ़िगरेशन का रेफ़रंस देखें.
  • एपीआई प्रॉक्सी बंडल का साइज़: एपीआई प्रॉक्सी बंडल का साइज़ 15 एमबी से ज़्यादा नहीं होना चाहिए. 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 for Private Cloud के 4.15.07 और उससे पहले के वर्शन में, मैसेज प्रोसेसर http.properties फ़ाइल में बदलाव करके, HTTPResponse.body.buffer.limit पैरामीटर की सीमा बढ़ाएं. प्रोडक्शन में बदलाव डिप्लॉय करने से पहले,
  • Edge for Private Cloud के वर्शन 4.16.01 और उसके बाद के वर्शन में, पेलोड वाले अनुरोधों में Content-Length हेडर शामिल होना चाहिए. इसके अलावा, स्ट्रीमिंग के मामले में "Transfer-Encoding: chunked" हेडर शामिल होना चाहिए. खाली पेलोड के साथ एपीआई प्रॉक्सी को पोस्ट करने के लिए, आपको Content-Length को 0 पर सेट करना होगा.
  • Edge for Private Cloud के 4.16.01 और उसके बाद के वर्शन में, सीमाएं बदलने के लिए, /opt/apigee/router.properties या message-processor.properties में ये प्रॉपर्टी सेट करें. ज़्यादा जानकारी के लिए, राउटर या मैसेज प्रोसेसर पर मैसेज के साइज़ की सीमा सेट करना देखें.

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

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

  • गड़बड़ी ठीक करने की सभी प्रोसेस को मैनेज करने के लिए, FaultRules का इस्तेमाल करें. (RaiseFault नीतियों का इस्तेमाल, मैसेज फ़्लो को रोकने और FaultRules फ़्लो पर प्रोसेसिंग भेजने के लिए किया जाता है.)
  • गड़बड़ी के जवाब बनाने के लिए, FaultRules फ़्लो में, AssignMessage नीतियों का इस्तेमाल करें, न कि RaiseFault नीतियों का. गड़बड़ी के टाइप के आधार पर, AssignMessage की नीतियों को शर्त के साथ लागू करें.
  • इसमें हमेशा डिफ़ॉल्ट 'सभी गड़बड़ियों को ठीक करने वाला' गड़बड़ी मैनेजर शामिल होता है, ताकि सिस्टम से जनरेट हुई गड़बड़ियों को, ग्राहक के तय किए गए गड़बड़ी के रिस्पॉन्स फ़ॉर्मैट पर मैप किया जा सके.
  • अगर हो सके, तो गड़बड़ी के जवाब हमेशा अपनी कंपनी या प्रोजेक्ट में उपलब्ध किसी भी स्टैंडर्ड फ़ॉर्मैट से मैच कराएं.
  • गड़बड़ी के ऐसे मैसेज इस्तेमाल करें जो काम के हों और जिन्हें कोई भी पढ़ सके. साथ ही, इन मैसेज में गड़बड़ी की स्थिति को ठीक करने का सुझाव भी दिया गया हो.

गड़बड़ियों को मैनेज करना लेख पढ़ें.

इंडस्ट्री के सबसे सही तरीकों के बारे में जानने के लिए, गड़बड़ी के जवाब के लिए, रिफ़्रेश किए जा सकने वाले एचटीटीपी (RESTful) का डिज़ाइन लेख पढ़ें.

परसिस्टेंस

की/वैल्यू मैप

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

की वैल्यू मैप ऑपरेशंस की नीति देखें.

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

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

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

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

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

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

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

  • जब भी हो सके, सबसे पहले बिल्ट-इन नीतियों का इस्तेमाल करें. Apigee की नीतियां बेहतर बनाई गई हैं, ऑप्टिमाइज़ की गई हैं, और इनका इस्तेमाल किया जा सकता है. उदाहरण के लिए, जब भी हो सके, पैकेज बनाने, पैकेज (XPath, JSONPath) से जानकारी निकालने वगैरह के लिए, JavaScript के बजाय, स्टैंडर्ड AssignMessage और ExtractVariables की नीतियों का इस्तेमाल करें.
  • Python और Java के मुकाबले, 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)

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

JavaScript

  • API Platform पर JavaScript, E4X के ज़रिए एक्सएमएल के साथ काम करता है.

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

Java

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

जवाब को Java कॉलआउट की मदद से कैपिटल लेटर में बदलना लेख पढ़ें.

Python

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

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

ServiceCallouts

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

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

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

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

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

AccessEntity की नीति

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

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

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

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

मैसेज लॉग करने की नीति देखें.

निगरानी

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

Apigee Analytics

गड़बड़ी के प्रतिशत को मेज़र करने की वजह से, Analytics, एपीआई की ऐसी मॉनिटरिंग कर सकता है जो गंभीर नहीं है.

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

ट्रेस

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

ट्रैक करने वाले टूल का इस्तेमाल करना लेख पढ़ें.

सुरक्षा

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