शुरुआती जानकारी

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

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

एपीआई प्रॉडक्ट क्या है?

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

खास तौर पर, एपीआई प्रॉडक्ट बंडल में इन चीज़ों को शामिल किया जाता है:

  • एपीआई संसाधनों का कलेक्शन (यूआरआई)
  • सर्विस प्लान
  • निगरानी या विश्लेषण के लिए आपके कारोबार का खास मेटाडेटा (ज़रूरी नहीं)

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

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

  • एपीआई प्रॉडक्ट, जो कम कीमत पर ऐक्सेस करने की सुविधा देता है. जैसे, मोल-भाव के लिए हर दिन 1,000 अनुरोध. दूसरा एपीआई प्रॉडक्ट, जो उन्हीं संसाधनों को ऐक्सेस करता है, लेकिन ऐक्सेस की सीमा ज़्यादा है और कीमत ज़्यादा है.
  • यह बिना शुल्क वाला एक एपीआई प्रॉडक्ट है, जो संसाधनों को रीड ओनली ऐक्सेस देता है. दूसरा एपीआई प्रॉडक्ट, जो कम शुल्क में उन ही रिसॉर्स को पढ़ने/लिखने का ऐक्सेस देता है.

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

एपीआई प्रॉडक्ट, आपके एपीआई ऐक्सेस करने की अनुमति देने और उसे ऐक्सेस करने का मुख्य तरीका है. Apigee में, एपीआई कुंजियों का प्रावधान किया जाता है. ये एपीआई प्रॉडक्ट के लिए नहीं होते, बल्कि एपीआई प्रॉडक्ट के लिए होते हैं. दूसरे शब्दों में, एपीआई कुंजियों में संसाधनों के बंडल के साथ-साथ एक सेवा प्लान अटैच होता है.

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

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

मुख्य कॉन्सेप्ट को समझना

अपने एपीआई प्रॉडक्ट बनाने से पहले, यहां दिए गए मुख्य कॉन्सेप्ट देखें.

एपीआई कुंजियां

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

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

  • एपीआई पासकोड की पुष्टि करने के लिए, ऐप्लिकेशन को सीधे उपभोक्ता पासकोड की पुष्टि करनी होगी.
  • जब एपीआई, OAuth टोकन की पुष्टि का इस्तेमाल करता है, तो ऐप्लिकेशन को एक टोकन पास करना होगा. इसे उपभोक्ता कुंजी से लिया गया है.

एपीआई पासकोड अपने-आप लागू नहीं होते. एपीआई प्रॉक्सी, आपके एपीआई प्रॉक्सी में अनुरोध के क्रेडेंशियल की पुष्टि करती है, चाहे वह ग्राहक कुंजी का इस्तेमाल हो या OAuth टोकन का, अनुरोध करने के तरीके के तौर पर. ऐसा करने के लिए, सही तरीके से पुष्टि करने के लिए एपीआई कुंजी की नीति या OAuth/VerifyAccessToken नीति को शामिल किया जाता है. अगर आपने एपीआई प्रॉक्सी में क्रेडेंशियल लागू करने से जुड़ी नीति शामिल नहीं की है, तो कोई भी कॉलर आपके एपीआई का इस्तेमाल कर सकता है. ज़्यादा जानकारी के लिए, एपीआई पासकोड से जुड़ी नीति की पुष्टि करें देखें.

अनुरोध में पास किए गए क्रेडेंशियल की पुष्टि करने के लिए, Edge इन चरणों को पूरा करता है:

  • अनुरोध के साथ पास किए गए क्रेडेंशियल पाएं. OAuth टोकन की पुष्टि के मामले में, Edge पुष्टि करता है कि टोकन की समयसीमा खत्म नहीं हुई है. इसके बाद, वह उपभोक्ता कुंजी देखता है जिसका इस्तेमाल टोकन को जनरेट करने के लिए किया गया था.
  • उन एपीआई प्रॉडक्ट की सूची वापस पाएं जिनसे उपभोक्ता कुंजी जुड़ी है.
  • पक्का करें कि एपीआई प्रॉडक्ट में मौजूदा एपीआई प्रॉक्सी को शामिल किया गया है. यह भी पक्का करें कि एपीआई प्रॉडक्ट पर मौजूदा रिसॉर्स पाथ (यूआरएल पाथ) चालू हो.
  • इस बात की पुष्टि करें कि उपभोक्ता कुंजी की समयसीमा खत्म न हुई हो या उसे वापस न ले लिया गया हो. जांच लें कि ऐप्लिकेशन को रद्द तो नहीं किया गया है. यह भी देखें कि ऐप्लिकेशन डेवलपर चालू है या नहीं.

अगर ऊपर बताई गई सभी जांच पास हो जाती हैं, तो क्रेडेंशियल की पुष्टि कर ली जाती है.

सबसे नीचे, Edge अपने-आप उपभोक्ता कुंजियां जनरेट करता है, लेकिन एपीआई पब्लिशर को सही नीतियों का इस्तेमाल करके, एपीआई प्रॉक्सी में कुंजी की जांच को लागू करना होगा.

अपने आप बनाम मैन्युअल मंज़ूरी

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

कोटा

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

कोटा कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, कोटा नीति देखें. कोटा नीतियों में प्रॉडक्ट कोटा सेटिंग का इस्तेमाल करने के बारे में जानकारी पाने के लिए, यह समुदाय लेख पढ़ें एपीआई प्रॉडक्ट पर कोटा की सेटिंग, एपीआई प्रॉक्सी में कोटा नीतियों के साथ कैसे इंटरैक्ट करती हैं?.

OAuth स्कोप

सुरक्षा के एक और लेवल के तौर पर, आप किसी भी OAuth स्कोप को कॉमा लगाकर अलग की गई सूची के तौर पर तय कर सकते हैं. यह सूची, प्रॉडक्ट से भेजे गए ऐक्सेस टोकन में मौजूद होनी चाहिए. कोई प्रॉडक्ट बनाते समय, आपको उन सभी दायरों के बारे में पता होना चाहिए जिनका इस्तेमाल आपका संगठन करता है. किसी प्रॉडक्ट में जोड़े गए स्कोप मौजूदा स्कोप से मेल खाने चाहिए. अगर ऐसा नहीं है, तो प्रॉडक्ट सुरक्षित नहीं है.

Edge OAuth नीतियों के साथ स्कोप का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, OAuth2 स्कोप के साथ काम करना देखें.

ऐक्सेस लेवल

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

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

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

ध्यान दें: ऐक्सेस लेवल निजी और संगठन में काम करने वाले लोगों के लिए अलग-अलग होते हैं. वह लेबल चुनें जो एपीआई प्रॉडक्ट के टारगेट ऑडियंस के बारे में सबसे सही जानकारी देता हो.

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

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