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

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

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

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

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

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

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

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

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

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

नाम रखने के तरीके

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

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

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

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

सीओआरएस चालू करना

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

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

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

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

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

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

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

  • अनुरोध और जवाब स्ट्रीम करें. ध्यान दें कि स्ट्रीम करने पर, नीतियों के पास मैसेज के कॉन्टेंट का ऐक्सेस नहीं रहता. स्ट्रीमिंग के अनुरोध और जवाब देखें.
  • Edge for Private Cloud के 4.15.07 और इससे पहले के वर्शन में, HTTPResponse.body.buffer.limit पैरामीटर में सीमा बढ़ाने के लिए, मैसेज प्रोसेसर http.properties फ़ाइल में बदलाव करें. प्रोडक्शन में बदलाव को डिप्लॉय करने से पहले, उसकी जांच ज़रूर कर लें.
  • Edge for Private Cloud के 4.16.01 और इसके बाद के वर्शन में, पेलोड वाले अनुरोधों में Content-Length हेडर शामिल होना चाहिए. अगर स्ट्रीमिंग की जा रही है, तो "Transfer-Encoding: chunked" हेडर शामिल होना चाहिए. अगर आपको किसी एपीआई प्रॉक्सी को खाली पेलोड के साथ POST करना है, तो आपको 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 error response design देखें.

परसिस्टेंस

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

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

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

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

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

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

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

जवाब को कैश मेमोरी में सेव करने से जुड़ी नीति देखें.

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

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

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

JavaScript

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

JavaScript की मदद से API प्रॉक्सी प्रोग्राम करना लेख पढ़ें.

Java

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

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

Python

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

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

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

JavaScript

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

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

Java

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

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

Python

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

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

ServiceCallouts

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

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

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

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

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

AccessEntity नीति

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

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

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

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

MessageLogging नीति देखें.

मॉनिटर करने के लिए

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

Apigee Analytics

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

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

ट्रेस

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

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

सुरक्षा

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