यहां Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
पर जाएं
Apigee X दस्तावेज़. info
यहां दिए गए सेक्शन में, एपीआई प्रॉडक्ट और उनसे जुड़े अहम कॉन्सेप्ट के बारे में बताया गया है.
एपीआई प्रॉडक्ट क्या है?
एपीआई उपलब्ध कराने वाले के तौर पर, एपीआई प्रॉडक्ट बनाकर अपने एपीआई को बंडल किया जा सकता है. साथ ही, उन्हें ऐप्लिकेशन डेवलपर के लिए उपलब्ध कराया जा सकता है. एपीआई प्रॉडक्ट को अपनी प्रॉडक्ट लाइन के तौर पर देखा जा सकता है.
खास तौर पर, एपीआई प्रॉडक्ट में ये चीज़ें शामिल होती हैं:
- एपीआई संसाधनों (यूआरआई) का कलेक्शन
- सेवा प्लान
- मॉनिटरिंग या विश्लेषण के लिए, आपके कारोबार से जुड़ा मेटाडेटा (ज़रूरी नहीं)
किसी एपीआई प्रॉडक्ट में बंडल किए गए एपीआई संसाधन, एक या उससे ज़्यादा एपीआई से आ सकते हैं. इसलिए, खास फ़ीचर सेट बनाने के लिए, संसाधनों को मिक्स और मैच किया जा सकता है. इसके बारे में, यहां दी गई इमेज में दिखाया गया है.
खास ज़रूरतों को पूरा करने वाले इस्तेमाल के उदाहरणों के लिए, कई एपीआई प्रॉडक्ट बनाए जा सकते हैं. उदाहरण के लिए, एक ऐसा एपीआई प्रॉडक्ट बनाया जा सकता है जिसमें मैपिंग के कई संसाधन बंडल किए गए हों. इससे डेवलपर, अपने ऐप्लिकेशन में आसानी से मैप इंटिग्रेट कर सकते हैं. इसके अलावा, हर एपीआई प्रॉडक्ट के लिए अलग-अलग प्रॉपर्टी सेट की जा सकती हैं. जैसे, अलग-अलग कीमत के लेवल. उदाहरण के लिए, एपीआई प्रॉडक्ट के ये कॉम्बिनेशन ऑफ़र किए जा सकते हैं:
- एक ऐसा एपीआई प्रॉडक्ट जो कम कीमत पर, ऐक्सेस की कम सीमा ऑफ़र करता है. जैसे, हर दिन 1,000 अनुरोध. दूसरा एपीआई प्रॉडक्ट, जो उन्हीं संसाधनों का ऐक्सेस देता है, लेकिन ऐक्सेस की ज़्यादा सीमा और ज़्यादा कीमत पर.
- एक ऐसा एपीआई प्रॉडक्ट जो मुफ़्त में, संसाधनों का रीड-ओनली ऐक्सेस ऑफ़र करता है. दूसरा एपीआई प्रॉडक्ट, जो कम शुल्क पर, उन्हीं संसाधनों का रीड/राइट ऐक्सेस ऑफ़र करता है.
इसके अलावा, किसी एपीआई प्रॉडक्ट में एपीआई संसाधनों के ऐक्सेस को कंट्रोल किया जा सकता है. उदाहरण के लिए, ऐसे संसाधन बंडल किए जा सकते हैं जिन्हें सिर्फ़ इंटरनल डेवलपर या सिर्फ़ पैसे चुकाने वाले ग्राहक ही ऐक्सेस कर सकते हैं.
एपीआई प्रॉडक्ट, आपके एपीआई के लिए अनुमति और ऐक्सेस कंट्रोल का मुख्य तरीका है. Apigee में, एपीआई पासकोड, एपीआई के लिए नहीं, बल्कि एपीआई प्रॉडक्ट के लिए उपलब्ध कराए जाते हैं. दूसरे शब्दों में, एपीआई पासकोड, संसाधनों के बंडल के लिए उपलब्ध कराए जाते हैं. इनमें सेवा प्लान भी शामिल होता है.
ऐप्लिकेशन डेवलपर, अपने ऐप्लिकेशन रजिस्टर करके आपके एपीआई प्रॉडक्ट को ऐक्सेस करते हैं. इसके बारे में, ऐप्लिकेशन रजिस्टर करना लेख में बताया गया है. जब कोई ऐप्लिकेशन, एपीआई प्रॉडक्ट को ऐक्सेस करने की कोशिश करता है, तो Apigee, रनटाइम पर अनुमति लागू करता है. इससे यह पक्का होता है कि:
- अनुरोध करने वाले ऐप्लिकेशन को, किसी खास एपीआई संसाधन को ऐक्सेस करने की अनुमति है.
- अनुरोध करने वाले ऐप्लिकेशन ने, अनुमति वाले कोटे को पार नहीं किया है.
- अगर एपीआई प्रॉडक्ट में OAuth के दायरे तय किए गए हैं, तो वे उन दायरों से मेल खाते हैं जो ऐप्लिकेशन के दिए गए ऐक्सेस टोकन से जुड़े हैं.
अहम कॉन्सेप्ट समझना
अपने एपीआई प्रॉडक्ट बनाने से पहले, यहां दिए गए अहम कॉन्सेप्ट की समीक्षा करें.
- एपीआई पासकोड
- पासकोड को अपने-आप मंज़ूरी मिलने बनाम मैन्युअल तरीके से मंज़ूरी मिलने की सुविधा
- कोटा
- OAuth के दायरे
- ऐक्सेस लेवल
एपीआई पासकोड
जब किसी डेवलपर के ऐप्लिकेशन को अपने संगठन में रजिस्टर किया जाता है, तो उसे कम से कम एक एपीआई प्रॉडक्ट से जोड़ा जाना चाहिए. किसी ऐप्लिकेशन को एक या उससे ज़्यादा एपीआई प्रॉडक्ट से जोड़ने पर, Edge उस ऐप्लिकेशन को एक यूनीक उपयोगकर्ता कुंजी असाइन करता है.
उपयोगकर्ता कुंजी या ऐक्सेस टोकन, अनुरोध क्रेडेंशियल के तौर पर काम करते हैं. ऐप्लिकेशन डेवलपर, उपयोगकर्ता कुंजी को ऐप्लिकेशन में एम्बेड करता है. इससे, जब ऐप्लिकेशन, Edge पर होस्ट किए गए किसी एपीआई के लिए अनुरोध करता है, तो वह अनुरोध में उपयोगकर्ता कुंजी को इनमें से किसी एक तरीके से पास करता है:
- जब एपीआई, एपीआई पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करता है, तो ऐप्लिकेशन को उपयोगकर्ता कुंजी सीधे तौर पर पास करनी होती है.
- जब एपीआई, OAuth टोकन की पुष्टि करने की सुविधा का इस्तेमाल करता है, तो ऐप्लिकेशन को ऐसा टोकन पास करना होता है जो उपयोगकर्ता कुंजी से जनरेट किया गया हो.
एपीआई पासकोड लागू करने की सुविधा अपने-आप काम नहीं करती. अनुरोध क्रेडेंशियल के तौर पर, उपयोगकर्ता कुंजी या OAuth टोकन का इस्तेमाल करने पर, एपीआई प्रॉक्सी, VerifyAPIKey नीति या OAuth/VerifyAccessToken नीति को सही फ़्लो में शामिल करके, आपके एपीआई प्रॉक्सी में अनुरोध क्रेडेंशियल की पुष्टि करती है. अगर एपीआई प्रॉक्सी में क्रेडेंशियल लागू करने की नीति शामिल नहीं की जाती है, तो कोई भी कॉलर आपके एपीआई को कॉल कर सकता है. ज़्यादा जानकारी के लिए, Verify API Key policy देखें.
अनुरोध में पास किए गए क्रेडेंशियल की पुष्टि करने के लिए, Edge ये चरण पूरे करता है:
- अनुरोध के साथ पास किए गए क्रेडेंशियल पाना. OAuth टोकन की पुष्टि करने के मामले में, Edge यह पुष्टि करता है कि टोकन की समयसीमा खत्म नहीं हुई है. इसके बाद, उस कंज्यूमर पासकोड को ढूंढता है जिसका इस्तेमाल टोकन जनरेट करने के लिए किया गया था.
- उन एपीआई प्रॉडक्ट की सूची पाना जिनसे उपयोगकर्ता कुंजी जोड़ा गया है.
- इस बात की पुष्टि करना कि मौजूदा एपीआई प्रॉक्सी, एपीआई प्रॉडक्ट में शामिल है या नहीं. साथ ही, यह पुष्टि करना कि मौजूदा संसाधन पाथ (यूआरएल पाथ), एपीआई प्रॉडक्ट पर चालू है या नहीं.
- यह पुष्टि करना कि उपयोगकर्ता कुंजी की समयसीमा खत्म नहीं हुई है या उसे रद्द नहीं किया गया है. साथ ही, यह पुष्टि करना कि ऐप्लिकेशन को रद्द नहीं किया गया है, और ऐप्लिकेशन डेवलपर सक्रिय है.
अगर ऊपर बताई गई सभी जांचें पूरी हो जाती हैं, तो क्रेडेंशियल की पुष्टि हो जाती है.
संक्षेप में, Edge, कंज्यूमर पासकोड अपने-आप जनरेट करता है. हालांकि, एपीआई पब्लिशर को सही नीतियां इस्तेमाल करके, एपीआई प्रॉक्सी में पासकोड की जांच लागू करनी होती है.
पासकोड को अपने-आप मंज़ूरी मिलने बनाम मैन्युअल तरीके से मंज़ूरी मिलने की सुविधा
डिफ़ॉल्ट रूप से, किसी ऐप्लिकेशन से एपीआई प्रॉडक्ट को ऐक्सेस करने के लिए पासकोड पाने के सभी अनुरोधों को अपने-आप मंज़ूरी मिल जाती है. इसके अलावा, एपीआई प्रॉडक्ट को मैन्युअल तरीके से पासकोड की मंज़ूरी देने के लिए कॉन्फ़िगर किया जा सकता है. इस मामले में, आपको ऐसे किसी भी ऐप्लिकेशन से पासकोड के अनुरोधों को मंज़ूरी देनी होगी जो एपीआई प्रॉडक्ट जोड़ता है. ज़्यादा जानकारी के लिए, ऐप्लिकेशन रजिस्टर करना और एपीआई पासकोड मैनेज करना लेख पढ़ें.
कोटा
कोटा की मदद से, ज़्यादा ट्रैफ़िक के लिए अपने बैकएंड सर्वर को सुरक्षित रखा जा सकता है. साथ ही, अपनी प्रॉडक्ट लाइन को अलग-अलग किया जा सकता है. उदाहरण के लिए, ज़्यादा कोटे वाले संसाधनों को प्रीमियम प्रॉडक्ट के तौर पर बंडल किया जा सकता है. साथ ही, कम कोटे वाले उसी बंडल को बुनियादी प्रॉडक्ट के तौर पर इस्तेमाल किया जा सकता है. अगर कोई प्रॉडक्ट लोकप्रिय है और उसे बड़ी संख्या में अनुरोध मिल रहे हैं, तो कोटा की मदद से अपने सर्वर को ज़्यादा लोड से बचाया जा सकता है.
कोटा कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, कोटा की नीति देखें. कोटा की नीतियों में प्रॉडक्ट कोटा सेटिंग का इस्तेमाल करने के बारे में जानकारी पाने के लिए, कम्यूनिटी का यह लेख पढ़ें How do the quota settings on an API product interact with quota policies in an API proxy?.
OAuth के दायरे
सुरक्षा का एक और लेवल जोड़ने के लिए, OAuth के दायरे तय किए जा सकते हैं. इन्हें कॉमा लगाकर अलग की गई लिस्ट के तौर पर तय किया जा सकता है, ये दायरे, प्रॉडक्ट के ज़रिए भेजे गए ऐक्सेस टोकन में मौजूद होने चाहिए. प्रॉडक्ट बनाते समय, आपको अपने संगठन के इस्तेमाल किए जाने वाले सभी दायरों के बारे में पता होना चाहिए. किसी प्रॉडक्ट में जोड़े गए दायरे मौजूदा दायरों से मेल खाने चाहिए. ऐसा न होने पर, प्रॉडक्ट सुरक्षित नहीं होता.
Edge OAuth की नीतियों के साथ दायरों का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, OAuth2 के दायरों के साथ काम करना लेख पढ़ें.
ऐक्सेस लेवल
एपीआई प्रॉडक्ट तय करते समय, ये ऐक्सेस लेवल सेट किए जा सकते हैं.
| ऐक्सेस लेवल | ब्यौरा |
|---|---|
| सार्वजनिक | ऐसे एपीआई प्रॉडक्ट जो सभी डेवलपर के लिए उपलब्ध हैं. इन्हें इंटिग्रेटेड या Drupal पर आधारित डेवलपर पोर्टल में जोड़ा जा सकता है. |
| सिर्फ़ निजी या इंटरनल इस्तेमाल के लिए | ऐसे एपीआई प्रॉडक्ट जो निजी या इंटरनल इस्तेमाल के लिए डिज़ाइन किए गए हैं. ध्यान दें: 'सिर्फ़ निजी इस्तेमाल के लिए' और 'सिर्फ़ इंटरनल इस्तेमाल के लिए' ऐक्सेस लेवल में कोई अंतर नहीं है. वह लेबल चुनें जो एपीआई प्रॉडक्ट के टारगेट ऑडियंस के बारे में सबसे अच्छी तरह बताता हो. इंटिग्रेटेड पोर्टल के लिए, 'सिर्फ़ निजी इस्तेमाल के लिए' या 'सिर्फ़ इंटरनल इस्तेमाल के लिए' एपीआई प्रॉडक्ट जोड़े जा सकते हैं. साथ ही, ज़रूरत के हिसाब से इन्हें ऐप्लिकेशन डेवलपर के लिए उपलब्ध कराया जा सकता है. Drupal पर आधारित डेवलपर पोर्टल के लिए, 'सिर्फ़ निजी इस्तेमाल के लिए' या 'सिर्फ़ इंटरनल इस्तेमाल के लिए' एपीआई प्रॉडक्ट के ऐक्सेस को अपने डेवलपर पोर्टल पर मैनेज किया जा सकता है. इसके बारे में, यहां दिए गए सेक्शन में बताया गया है:
|